Closed Bug 1552154 Opened 5 months ago Closed 2 months ago

Stop storing native code offset for each bytecode pc in BaselineScript


(Core :: JavaScript Engine: JIT, task, P2)




Tracking Status
firefox69 --- wontfix
firefox70 --- fixed


(Reporter: jandem, Assigned: jandem)




(6 files)

BaselineScript::nativeCodeForPC has the following consumers:

  1. Ion bailouts
  2. DebugModeOSR
  3. Exception handling
  4. OSR
  5. Profiler (also BaselineScript::approximatePcForNativeAddress)

I'm hoping we can change 1-3 to resume in the interpreter instead, once it's enabled by default (we would switch to Baseline JIT code at the next loop edge or call).

For 4 we only care about JSOP_LOOPENTRY ops. When the profiler is enabled we could choose to record more offsets but we wouldn't have to do this for every op - it would be more of a heuristic.

This should speed up BaselineCompiler a bit, use less memory, and simplify the code a bit (no need to handle and worry about unsynced stack values for example).

Type: defect → task
Priority: -- → P2
Depends on: 1567438
Assignee: nobody → jdemooij

Because DebugTrapEntries are only present if the script has debugger instrumentation
it should be fine to store this as a simple list of entries.

Depends on D40947

Depends on: 1567920
Pushed by
part 1 - Use mozilla::Span<> in BaselineScript, clean up RetAddrEntry code a bit. r=tcampbell
part 2 - Stop using pc-to-native map for OSR into Baseline JIT. r=tcampbell
part 3 - Stop using pc-to-native map for BaselineScript::computeResumeNativeOffsets. r=tcampbell
part 4 - Stop using pc-to-native map for BaselineScript::approximatePcForNativeAddress. r=tcampbell
part 5 - Stop using pc-to-native map for BaselineScript::toggleDebugTraps. r=tcampbell
part 6 - Remove BaselineScript's pc-to-native map. r=tcampbell
You need to log in before you can comment on or make changes to this bug.