Closed
Bug 1515934
Opened 5 years ago
Closed 5 years ago
findDebuggerInVector<T> triggers read barriers when T=ReadBarriered<Debugger*>
Categories
(Core :: JavaScript: GC, enhancement, P5)
Tracking
()
RESOLVED
FIXED
mozilla72
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
Details
Attachments
(2 files)
This isn't supposed to happen due to implementing js::detail::DefineComparisonOps<> for ReadBarriered<T>. Equality test of a ReadBarriered pointer and a raw pointer is supposed to skip the barrier.
|
Assignee | |
Updated•5 years ago
|
Assignee: nobody → jcoppeard
|
|
Assignee | |
Comment 1•5 years ago
|
||
This should have been obvious; we didn't end up declaring ElementType on WeakHeapPtr.
Depends on D54551
|
|
Assignee | |
Comment 2•5 years ago
|
||
Depends on D54552
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/40e41bd4e41f Don't trigger WeakHeapPtr read barrier on comparison r=sfink https://hg.mozilla.org/integration/autoland/rev/7a5fc4784185 Add jsapi tests for read barriers r=sfink
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/40e41bd4e41f
https://hg.mozilla.org/mozilla-central/rev/7a5fc4784185
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox72:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in
before you can comment on or make changes to this bug.
Description
•