Closed Bug 1157967 Opened 5 years ago Closed 4 years ago

Investigate making the pre-barriers push unilaterally

Categories

(Core :: JavaScript: GC, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox40 --- affected

People

(Reporter: terrence, Unassigned)

References

(Blocks 1 open bug)

Details

The pre-barriers currently call directly into the normal marking paths. This means that we end up using the marking path optimizations, which are, arguably, not wanted in this case. Specifically, marking is tuned for throughput when in processMarkStackTop with little consideration given to latency since we have 10ms slices. On the other hand, doing the amount of work implied by a full Rope or Shape traversal on assignment is probably not ideal.

This should be relatively simple to implement: switch the barrrier tracer over to a new JSTracer kind with its own mark stack instance. Marking for this new tracer would unconditionally push the target pointer into that separate stack. At the top of each slice call TraceEdge on every pointer in this stack.

There are some concerns here: (1) We end up using our entire slice to process the work done between slices and make no forward progress in marking. (2) Alternatively, can we incrementalize it somehow so that we can fall behind to keep our max-pause low even with high mutator usage? (3) new OOM paths to handle somehow.
Also of note: this would allow us to remove several isTenured checks in warm marking loops that are necessary right now because these paths are used between slices.
This works, but makes things generally less incremental.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.