Closed
Bug 842137
Opened 12 years ago
Closed 9 years ago
Don't add intrazone cross-compartment edges during zone-merging cycle collections
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: mccr8, Unassigned)
References
(Blocks 1 open bug)
Details
With compartment-merging CCs, I avoided self-edges by only looking at the table of cross compartment wrappers to find JS objects. In a zone-merging CC, some of these CCWs will be intrazone pointers, and thus add useless self-edges to the CC graph. I'm not sure how many of these edges there will actually end up being. It would probably be a good idea to investigate what zone-merging CCs look like in general, to confirm my intuition that they are strictly better than compartment-merging CCs. Zone merging should produce strictly smaller graphs than compartment merging, but it is somewhat possible it will cause problems for my hacky scheduling heuristics. I'm not sure if there's any more clever way to detect these edges than explicitly checking if the zone of each child is equal to the parent's zone in the zone CC participant.
Reporter | ||
Updated•12 years ago
|
Comment 1•12 years ago
|
||
/me needs to understand what zone-merging CC means.
Reporter | ||
Comment 2•12 years ago
|
||
Right now, on page teardown (ideally) we represent all of the JS in a single compartment as a single node in the CC graph. In the bug that is blocking this, Bill is changing things so that multiple compartments can be stored in the same set of GC arenas. This does not affect cross-compartment wrappers. The goal is to reduce the overhead for a compartment. There's one zone for chrome compartments, and another for the content in each tab, more or less. Because of the change in representation, you can't iterate over just a compartment anymore, you have to iterate over an entire zone. Thus Bill is changing compartment-merging CCs to zone-merging CCs.
Comment 3•12 years ago
|
||
Well, can't you still iterate over a compartment if you iterate over zone and compare the compartment... but ok, zone-merging sounds like a good thing when closing a tab.
Reporter | ||
Comment 4•12 years ago
|
||
Yeah, it would be more expensive, and zone merging is probably what we want anyways.
Updated•12 years ago
|
Priority: -- → P3
Reporter | ||
Comment 5•9 years ago
|
||
I think this is not a big deal. The bigger problem is that we don't run zone merging CCs much or at all any more...
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•