Open Bug 1868625 Opened 1 year ago Updated 1 year ago

Consider triggering a CC for revived system compartments

Categories

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

task

Tracking

()

People

(Reporter: sfink, Unassigned)

References

(Blocks 1 open bug)

Details

Bug 1868437 disables the COMPARTMENT_REVIVED mechanism for system compartments. The mechanism is for clearing out zombie compartments that are only being kept alive by barriers or Gecko reference cycles.

This introduces the possibility of piling up zombie system compartments until a CC runs. There is already a mechanism for triggering a CC when we see gray-only compartments piling up, but the way bug 1868437 disables the mechanism means it will no longer apply to system compartments.

We could separate these two: do not do COMPARTMENT_REVIVED GCs for system compartments, but do consider them when deciding whether to trigger a cycle collection.

In terms of code, this would mean:

  • do not set maybeAlive based on invisibleToDebuggers (aka isProbablySystemCompartment)
  • change the shouldRepeatForDeadZone logic to if (c->gcState.scheduledForDestruction && !c->invisibleToDebuggers)
  • gate the maybeDoCycleCollection() on the existing shouldRepeatForDeadZone that ignores invisibleToDebuggers

(We'd probably parameterize shouldRepeatForDeadZone.)

This would require an extra GC cycle to discard those compartments, but I assume the CC will trigger a GC anyway, and the only point is to avoid system compartments piling up between CCs.

Blocks: GC.size
Severity: -- → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.