...
Some things to look out for: - We could do this severing at GC finalization time (or on every Nth GC, or some other heuristic piggy backing on GC timing). - If it's on the stack, we can't throw it away, at least not naively. We could make a GC managed stub. But it might be simplest to just skip tossing it away if it's on the stack and wait until next GC cycle. - If an OSR exit has been wired to jump to baseline code, we can't throw it away, at least not naively. We could toss the OSR exit ramp code and rebuild it. Alternatively, we could just skip throwing away any such baseline code. It might be a good heuristic anyways to keep baseline code that's been existed to.
(In reply to Saam Barati from comment #1) > Some things to look out for: > - We could do this severing at GC finalization time (or on every Nth GC, or > some other heuristic piggy backing on GC timing). > - If it's on the stack, we can't throw it away, at least not naively. We > could make a GC managed stub. But it might be simplest to just skip tossing > it away if it's on the stack and wait until next GC cycle. > - If an OSR exit has been wired to jump to baseline code, we can't throw it > away, at least not naively. We could toss the OSR exit ramp code and rebuild > it. Alternatively, we could just skip throwing away any such baseline code. > It might be a good heuristic anyways to keep baseline code that's been > existed to. - We also need to unlink any incoming calls.
Created attachment 380382 [details] WIP
perf seems neutral on Speedo2 and JS2
Created attachment 380710 [details] WIP