Proposal: Polymorphic Inline Cache (PIC) for Property Access

[akash-R-A-J]

Background

Currently Boa uses a monomorphic inline cache for property access sites, storing only a single (WeakShape, Slot) pair. When a shape mismatch occurs, the cache is reset, discarding the previous entry.

This causes constant cache invalidation when the same property is accessed on objects with different shapes, which is very common in JavaScript. As a result, many polymorphic access sites fall back to the slow path repeatedly.

Example

function getX(o) { return o.x; }

getX({x:1});
getX({x:2,y:3});
getX({x:5,z:7});

Each object has a different shape, so the current inline cache thrashes and provides little benefit.

Proposed Improvement

One possible improvement would be to upgrade the monomorphic inline cache to a polymorphic inline cache (PIC) that stores multiple (Shape → Slot) mappings per access site. Many modern engines (e.g., V8, SpiderMonkey) use small PICs (commonly 4 entries) to efficiently handle polymorphic property access.

High-level idea:

• Cache up to N shape → slot mappings (e.g., N = 4)
• On lookup, check cached entries for a matching shape
• If the number of observed shapes exceeds N, transition to a megamorphic state and fall back to the slow path

Expected Benefit

This could reduce inline cache thrashing and improve performance for polymorphic property accesses.

If this approach seems reasonable, I would be happy to work on an implementation.

[akash-R-A-J]

Hi @jedel1043, I'd like to work on this issue. Could you please assign it to me?