Skip to content

Inline caching for property lookups and function calls #71

Description

@pmatos

Description

Every property access (obj.prop, obj[key]) currently walks the full property lookup chain: check proxy → module namespace → typed array → own properties HashMap → prototype chain. Every function call goes through: proxy check → wrapped function check → class constructor check → callable extraction. These checks are redundant when the same access site hits the same object shape repeatedly (monomorphic access).

Inline caching (IC) records the object shape (hidden class / map) at each access site and caches the lookup result. On subsequent accesses, if the shape matches, the cached result is used directly — skipping the entire lookup chain.

Motivation

Mandreel (#54) accesses global typed arrays (heap32, heapU32, etc.) millions of times from the same call sites. Each access walks the scope chain to find the global, then walks get_object_property to find the typed array element. With IC, the second and subsequent accesses at the same site would be a single shape check + direct memory access.

Similarly, function calls in mandreel's emulated C code (849 functions) are always the same function at each call site. IC would cache the callable, skipping proxy/class-constructor/wrapped-function checks.

Scope

  • Implement hidden classes / shapes for objects (track property layout)
  • Add inline cache slots to property access and call bytecode instructions
  • Implement monomorphic and polymorphic IC strategies
  • Fall back to megamorphic (full lookup) when shapes are too diverse
  • Requires bytecode compiler (depends on the bytecode issue)

References

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions