Bug 202503 - Investigate throwing away baseline code when tiering up
Summary: Investigate throwing away baseline code when tiering up
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Saam Barati
URL:
Keywords:
Depends on: 197993
Blocks:
  Show dependency treegraph
 
Reported: 2019-10-02 16:57 PDT by Saam Barati
Modified: 2019-10-10 18:17 PDT (History)
12 users (show)

See Also:


Attachments
WIP (69.30 KB, patch)
2019-10-07 18:43 PDT, Saam Barati
no flags Details | Formatted Diff | Diff
WIP (96.50 KB, patch)
2019-10-10 18:17 PDT, Saam Barati
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Saam Barati 2019-10-02 16:57:23 PDT
...
Comment 1 Saam Barati 2019-10-02 18:08:39 PDT
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.
Comment 2 Saam Barati 2019-10-02 18:09:21 PDT
(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.
Comment 3 Saam Barati 2019-10-07 18:43:40 PDT
Created attachment 380382 [details]
WIP
Comment 4 Saam Barati 2019-10-08 19:57:33 PDT
perf seems neutral on Speedo2 and JS2
Comment 5 Saam Barati 2019-10-10 18:17:26 PDT
Created attachment 380710 [details]
WIP