The dead compartment logic (see bug 1016738) triggers non-incremental GCs if it detects that compartments that should have been collected were not collected. The problem is that page navigation causes wrapper remapping which can cause a lot of dead things to be marked (via triggering barriers). This is a problem on our reftests which could end up with hundreds of uncollected compartments. However this is also showing up when looking at performances issues (e.g. bug 1269695). These GCs are meant to be fast but in this case I'm seeing them take a couple of hundred milliseconds. This is because we can only collect down to the resolution of a zone, and there may still be many active compartments in that zone. It should be possible to change the heuristics to limit this cleanup to the situation to where there are many uncollected compartments so we don't get these long GCs so often in real world use but also don't have runaway compartment growth when running our tests.

This appears to be a big problem based on bug 1314828. Please let me know if I can help, although I don't remember too much about it.

(In reply to Bill McCloskey (:billm) from comment #1) I wondering if we can make wrapper remapping lazy somehow. This would avoid the overhead of doing it for these dead compartments as well as the cost of keeping them alive unnecessarily.

(In reply to Jon Coppeard (:jonco) from comment #2) I spent a while working on making wrapper remapping lazy but this proved problematic because it meant that remapping could happen in all sorts of unexpected places later on, for example when querying flags on a wrapper.

From the comments in bug 1314828 comment 2, it seems the situation is much improved since bug 1318384 landed.