Closed Bug 1581574 Opened 2 months ago Closed 2 months ago

Investigate removing Heap<T>'s pre write barrier

Categories

(Core :: JavaScript: GC, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: jonco, Assigned: jonco)

Details

Attachments

(1 file)

Inside the engine we use the pre write barrier to enforce the snapshot at the beginning invariant, which enables incremental marking.

Without this it would be possible to read a not-yet-marked value and write it into an marked location and overwrite the original value, with the result that the value does not end up marked yet is still reachable. The write barrier solves this by marking the original value when we overwrite it. It's a conservative approach because the original value may not be used again and might now be unreachable, in which case we are keeping garbage alive.

Despite being conservative, write barriers are preferable to read barriers for performance reasons, since writes are generally less frequent than reads. However for the Heap<T> case we already have a read barrier which we use to make sure gray things become black when they are read out of the heap. This barrier also marks things black during an incremental GC:

https://searchfox.org/mozilla-central/source/js/public/HeapAPI.h#607-608

So maybe we don't need the write barrier after all. Removing this would potentially allow us to collect some garbage sooner.

Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/394cb5645323
Remove Heap<T> write barrier and rely on existing read barrier to make incremental marking work r=sfink
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
You need to log in before you can comment on or make changes to this bug.