Open Bug 1894940 Opened 1 year ago Updated 1 year ago

Improve heuristics around discarding JIT code

Categories

(Core :: JavaScript: GC, enhancement, P3)

Product:
Core
Component:
JavaScript: GC
Type:
enhancement

Tracking

()

People

(Reporter: jonco, Assigned: mgaudet)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Whiteboard: [sp3])

Currently we have a bunch of heuristics about when to throw away JIT code (see GCRuntime::shouldPreserveJITCode) but this ultimately operates at the granularity of a zone. So either all JIT code in a zone is preserved or it's all thrown away. This has the problem that we can both throw away JIT code too eagerly causing performance issues, and we can throw it away too lazily causing increased memory use and GC time.

One approach is to track which JIT code has been executed since some previous point in time. This could be implemented using trampolines to set a flag the next time a piece of JIT code is executed. This could give us much better information about what we can throw away.

Trampoline are a good idea, but they only report which function is being called directly not which function might be called from any other JIT-ed function.
Similarly, monitoring functions which are calling into the VM would be one way, but they might hide some functions which are not relying on any VM calls, such as tiny functions or function using self-hosted code only.

I think the trampoline idea would be interesting if combined with an approximation of the call graph. In which case we could "protect" the closure of the call-graph when the JIT preserve mode is enabled.

Severity: -- → N/A
Priority: -- → P3
Whiteboard: [sp3]
See Also: → 1717917
Depends on: 1841244
Assignee: nobody → mgaudet

So playing with this a bit I have a pair of patches:

  1. They add a bit on the jitscript which is set when jit code is invoked
  2. That bit is in turned cleared when tracing for GC -- so we can tell the difference between code executed since the last GC
  3. Then I added a bit to the basescript. This is set when we clean up code that has the executed bit set.
  4. Then I added logging code for when we recompile a script which has the basescript flag set.

Here's a profile of SP3 running:

https://share.firefox.dev/4eSMyY8

Observations:

  1. Most recompilation is Baseline (as expected)
  2. Most recompilation is self-hosted: Also expected. Bryan's work on caching self-hosted scripts should hnelp wtih this.

There are fewer than I expected, but probably still sufficient working on this might help.

You need to log in before you can comment on or make changes to this bug.