Unmark arenas concurrently with mutator at the start of GC
Categories
(Core :: JavaScript: GC, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details |
As discussed in bug 1661872, we should be able to unmark GC things concurrently with the mutator at the start of GC. This means that the true start of GC would be in a second (or later slice) when we mark the roots, with previous slices setting up and polling for background unmarking work to finish.
Comment 1•4 years ago
|
||
This can be done concurrently? Oh... the mark bits are atomic now!
Assignee | ||
Comment 2•4 years ago
|
||
This adds a new background task for unmarking which gets kicked off in the
first GC slice. There's a new explicit 'prepare' state for both the GCRuntime
and zones. The GC proper starts in a second (or later) slice when this has
finished. Because of this we have to be a bit careful when checking GC
state because the 'prepare' state is not part of the GC from the point of view
of snapshot-at-the-beginning.
I had to update a bunch of test code that assumed that GC started in the mark
state.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
This adds a new background task for unmarking which gets kicked off in the
first GC slice. There's a new explicit 'prepare' state for both the GCRuntime
and zones. The GC proper starts in a second (or later) slice when this has
finished. Because of this we have to be a bit careful when checking GC
state because the 'prepare' state is not part of the GC from the point of view
of snapshot-at-the-beginning.
I had to update a bunch of test code that assumed that GC started in the mark
state.
This fixes cancelleling a parallel task in the case that the task was idle so
that it doesn't leave the cancel flag set.
Also it stops us sending telemetry about how much was collected in GCs that
were reset as we don't always have the data for the original heap sizes by this
point if the reset happened while we were in the prepare phase.
Finally there's a new zeal mode to test this, named YieldBeforeRootMarking
(slightly confusing but in line with the other modes).
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Backed out for failures on ProtectedData.h.
Backout link: https://hg.mozilla.org/integration/autoland/rev/7a6d6b986a1ed263db6d19ecbd56e2f4210870cf
Failure log: https://treeherder.mozilla.org/logviewer?job_id=324141721&repo=autoland&lineNumber=8246
https://treeherder.mozilla.org/logviewer?job_id=324127951&repo=autoland&lineNumber=1627
Comment 7•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•