780960 - GC: Incremental sweeping by compartment

Status: RESOLVED DUPLICATE of bug 790338

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

There are various parts of the sweep phase that will be difficult to incrementalize individually. However, we should be able to sweep compartments incrementally like this:

slice n: sweep compartments C1 and C2
slice n+1: sweep compartment C3
slice n+2: sweep compartments C4 and C5

Between slices n and n+1, we would have to continue marking compartments C3, C4, and C5. So their incremental barriers would have to be enabled, and we would have to call drainMarkStack in slices n+1 and n+2. Hopefully, though, not much additional marking would be needed.

On complication here is that if we decide to mark something in compartment C3 between slices n and n+1, it might reach a cross-compartment wrapper that points to an unmarked object in compartment C2. We would be in trouble if that happened, because all the unmarked objects in C2 have already been swept at this point.

However, we should be able to order the sweeping of compartments so that this never happens. If compartment C has an unmarked edge to C', then we need to sweep C before C'. In the event of cycles, all the compartments in the cycle need to be swept in the same slice.

I think that most of the work in this bug will be fixing up the sweeping code so that it's totally compartmentalized. We'll need to be able to sweep one compartment independent of other compartments, even if the other ones are also being collected in this GC. It looks like we'll have to fix up sweeping related to debuggers, weakmaps, and xpconnect. There may also be some nastiness with gray marking.

The things that could doom this approach are:
1. A huge cycle of compartments that forced them all to be swept in the same slice. In my experience, content compartments usually don't have incoming edges, so this seems likely to be okay.
2. If most of the sweep time is spent sweeping one big compartment, then this won't work. I haven't measured this yet, but we should do so. I think CPG makes this less likely, since there isn't just one big chrome compartment that could get in the way.

We should file separate bugs for fixing up pieces like gray marking and xpconnect. This bug can be used for actually breaking apart the sweeping of compartments.

Comment 1

[Andrew McCreight [:mccr8]]

> 2. If most of the sweep time is spent sweeping one big compartment, then this won't work.

That does seem pretty unlikely in my judgement from staring at post-CPG about:memory, assuming sweep time is proportional to compartment time.

I can also imagine different heuristics for deciding how to split up compartment sweeping, once independence has been achieved (time based, content compartments alone, etc.).

Comment 2

[Andrew McCreight [:mccr8]]

> assuming sweep time is proportional to compartment time.

I meant, compartment size, of course.