Remove BaselineDebugModeOSRInfo and trampoline
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(2 files)
Once the Baseline JIT can no longer be enabled without the Baseline Interpreter, we can remove BaselineDebugModeOSRInfo
and simplify BaselineDebugModeOSR a bit. I prototyped it yesterday and this should remove a few hundred lines of complicated code. It will also fix some tricky leaks that Gary has been finding with LeakSanitizer.
Assignee | ||
Comment 1•5 years ago
|
||
Er, we can't remove the whole mechanism, but we can remove the BaselineDebugModeOSRInfo
data structure, one of the most complicated parts.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
At this point most of the DebugModeOSR complexity came from dealing with the
On -> Off case because debugger callVMs are not present in the recompiled script.
We also had to worry about loading unsynced stack values in R0/R1 in the
DebugTrap case (because it resumes at the start of a bytecode op).
We can now change these cases to resume after the corresponding Interpreter
callVMs instead. This lets us remove BaselineDebugModeOSRInfo and the
continuation fixer trampoline. We also no longer have to worry about unsynced
R0/R1 stack values for DebugTrap because the interpreter always has a synced
stack at the beginning of a bytecode op.
This removes about 360 lines of complicated code. It also fixes a memory leak the
fuzzers found a few days ago (bug 1566189).
Assignee | ||
Comment 3•5 years ago
|
||
The call needs to be part of the bytecode op for the JIT, but the interpreter can emit
a single call at the end. Results in more compact code and we can now assert unique
callVMs in recordCallRetAddr.
Depends on D38477
Comment 5•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/49a2da59aa3e
https://hg.mozilla.org/mozilla-central/rev/499c8fa689ad
Description
•