Investigate removing baseline JIT guards for otherwise-dead GC things
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox117 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3])
Attachments
(9 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
This is something that has been talked about for a while. It would make some edges from JIT code weak, and sweep them when their referent died. This would also need to update JIT data structures appropriately, which may be complicated.
Without this we may be keeping garbage alive longer than necessary, and this may be affecting Speedometer3 (see bug 1821293 comment 0) although the evidence is mixed. Regardless, this would be a good improvement to make.
There is a risk that this would increase GC sweeping time but I don't have a feel for whether this will be significant on not.
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
| Assignee | ||
Comment 2•2 years ago
|
||
Jan can you take a look at the patch when you get a moment and let me know what you think?
Comment 3•2 years ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #2)
Jan can you take a look at the patch when you get a moment and let me know what you think?
(I commented on the patch. Approach makes sense to me, thanks for looking into this. Probably worth getting some data to see how it behaves in practice.)
| Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Comment 5•2 years ago
|
||
Along the same lines as the previous patch, sweep object pointers stored in baseline ICs.
Depends on D180857
| Assignee | ||
Comment 6•2 years ago
|
||
We skip the extra discard if we run all the way through to sweeping without
yielding, but if we start a slice in the prepare phase we will do an
unnecessary extra discard. This is probablly quite common since we always yield
at the start of an incremental GC, and budget can be long if we run in idle
time.
Using the flag rather than checking initialState makes it clearer what's going on.
Depends on D181982
| Assignee | ||
Comment 7•2 years ago
|
||
This is a very minor change to cancel off-thread compilation as soon as
possible rather than leaving it running while we set up a bunch of other
sweeping work.
Depends on D181983
| Assignee | ||
Comment 8•2 years ago
|
||
This is an optimisation so we don't repeatedly loop over all scripts in a zone
as there can be very many of these (e.g. 50000 is not unusual to see while
browsing around).
This adds the option to sweep JIT scripts as part of the discard options.
Depends on D181984
| Assignee | ||
Comment 9•2 years ago
•
|
||
Updating title to reflect what these patches do.
What they don't do is to remove edges from Ion code to dead GC things. They also don't handle the multiple shape guard IC. These are opportunities for future improvement in this area.
| Assignee | ||
Comment 10•2 years ago
|
||
To make the edges for the multiple shape guard weak we need a way to find and
update the objects used to hold these edges. The simplest way to do this is to
add a vector in the zone. I don't believe that there are not huge numbers of
these objects.
| Assignee | ||
Comment 11•2 years ago
|
||
Currently we iterate all BaseScripts to find the JitScripts in a zone. This is
inefficient since there can be many times more BaseScripts that JitScripts
(e.g. 10 - 20 times more).
Instead, keep all JitScripts in a zone in a linked list and use that to iterate
through them. This required giving JitScript a pointer to its owning JSScript
since that was needed in a few cases.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
Backed out for causing high frequency failures complaining about WarpOracle.cpp.
Backout link: https://hg.mozilla.org/integration/autoland/rev/70723ef5e495c2d58c42a340eebd16aeface5e09
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=421444827&repo=autoland&lineNumber=8140
https://treeherder.mozilla.org/logviewer?job_id=421456985&repo=autoland&lineNumber=21690
| Assignee | ||
Comment 15•2 years ago
|
||
The previous patch can remove stubs and since we don't know whether an
individual stub is a folded stub the flag can remain set after all folded
stubs are removed. This patch renames the flag to make this possibility
clearer.
Depends on D180857
Comment 16•2 years ago
|
||
Backed out for causing multiple failures.
- Push with failures - dt
- Failure Log
- Failure line: PROCESS-CRASH | MOZ_ASSERT(!tc->isMarkedGray()) [@ js::gc::detail::AssertCellIsNotGray] | devtools/client/framework/browser-toolbox/test/browser_browser_toolbox_fission_inspector.js
- Push with failures - c
- Failure Log
- Failure line: PROCESS-CRASH | application crashed [@ ExecutionObservableRealms::shouldRecompileOrInvalidate] | devtools/shared/webconsole/test/chrome/test_jsterm_autocomplete.html
Also these dt failures
Comment 17•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 18•2 years ago
|
||
For anyone trying to make sense of this, the push in comment 17 was before the backout in comment 16.
Why this is bouncing: I forgot that there's more to iterating scripts than just handing out the scripts themselves. Zone has two iterators for cells (cellIter and cellIterUnsafe) and the former does two extra things that the latter does not: it filters out dead scripts during incremental sweeping and it calls ExposeToActiveJS on the cells returned. Both of these turn out to be necessary for the debugger use of script iteration.
Comment 19•2 years ago
|
||
Comment 20•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3343587b5848
https://hg.mozilla.org/mozilla-central/rev/c444e4828105
https://hg.mozilla.org/mozilla-central/rev/1a7f294165fb
https://hg.mozilla.org/mozilla-central/rev/14eb54dfd045
https://hg.mozilla.org/mozilla-central/rev/0beee0368a67
https://hg.mozilla.org/mozilla-central/rev/2e6dbb731bf4
https://hg.mozilla.org/mozilla-central/rev/ba12c0cbb7a4
https://hg.mozilla.org/mozilla-central/rev/9882c0d924b8
https://hg.mozilla.org/mozilla-central/rev/325f1a934370
https://hg.mozilla.org/mozilla-central/rev/74c699614101
Comment 21•2 years ago
|
||
Wins on AWFY-Jetstream2:
Regressions on AWFY-Jetstream2:
Updated•2 years ago
|
Updated•2 years ago
|
Description
•