1914680 - CacheIR Heuristic idea: Decaying stubs (2 versions)

Status: NEW

(Core :: JavaScript Engine, task, P5)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

One idea that keeps bouncing around in my head is handling with grace "startup" stubs; the idea being that maybe a function is using different types and paths across the first N calls, but evetually hits some stability.

Right now, that means we would render this stub chain as ineligible for CacheIR transpilation.

Two relatively simple heuristics to address these kinds of problems occur to me:

1. When attaching a new stub, and the stub you're replacing as the head of the chain has an entry count of <1, then unhook the old stub before attaching the new one.

2. Stubs have another counter, a 'decay' counter. The decay counter would be initialized to some N (100?) on each entry, then when a stub hits, the stub after has its decay counter decremented. When identifying if a CacheIR chain is transpilable, instead of merely checking if length=1, we can then also see if length > 1, but the decay counter is negative, we can assume the stubs are not helping. We could also unlink these stubs when we do GC.

(If you squint, you could say that 1 is kind of a degenerate form of 2)