Add a read barrier when constructing JS::Heap<T>
Categories
(Core :: JavaScript: GC, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox95 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(3 files)
Heap<T> has a read barrier when extracting the contained value, but this it doesn't when constructing one from another Heap<T> (in either the copy or move constructor). The current barriers are designed to unmark gray values that may be passed into the engine, and such a barrier is not required for that.
With incremental gray marking we need to ensure that we don't move gray roots behind the marking wavefront, which would allow live to things to go unmarked. It would be possible to do this by copying or moving a Heap<T>. For example, you could std::swap two of these between marking slices.
To close this loophole we can add a read barrier on construction. It doesn't have to do gray unmarking but just needs to do an incremental read barrier and mark the value black if we're currently marking the zone.
Assignee | ||
Comment 1•3 years ago
|
||
This already had code to check both black and gray bit since that's needed to
work out whether something is marked gray. We can do the black check first and
bail early which skips calling into the JS engine for black things.
Depends on D127671
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D127672
Assignee | ||
Comment 3•3 years ago
|
||
Depends on D127673
Comment 5•3 years ago
|
||
Backed out along with Bug 1734362 for bustages on TestJSHolderMap.cpp - see comment
Assignee | ||
Updated•3 years ago
|
Comment 8•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4a23cc095af5
https://hg.mozilla.org/mozilla-central/rev/d1724fd8bf2b
https://hg.mozilla.org/mozilla-central/rev/d69187f5ce74
Description
•