1548138 - [jsdbg2] js::Debugger::generatorFrames lacks parallel entries in JS::Compartment::crossCompartmentWrappers

Status: NEW

(Core :: JavaScript Engine, task, P3)

Description

[Jim Blandy :jimb]

Debugger creates entries in js::Debugger::generatorFrames without creating parallel entries in JS::Compartment::crossCompartmentWrappers, as required for GC.

As explained in the patches for bug 1546817, entries in Debugger's cross-compartment weak maps all need parallel entries in the Debugger's compartments crossCompartmentWrappers map, so that partial GC's can find the incoming edges. generatorFrames does not follow that rule.

However, as explained in bug 1547042, Debugger's weak maps are generally redundant: as long as parallel entries are needed in crossCompartmentWrappers anyway, Debugger should just use that and be done with it.

So the proper fix is probably to delete js::Debugger::generatorFrames altogether, and instead extend CrossCompartmentKey with a new kind of key and just use crossCompartmentWrappers to associate AbstractGeneratorObjects with their Debugger.Frame counterparts.

Comment 1

[Jim Blandy :jimb]

(In reply to Jim Blandy :jimb from comment #0)

However, as explained in bug 1547042, Debugger's weak maps are generally redundant: as long as parallel entries are needed in crossCompartmentWrappers anyway, Debugger should just use that and be done with it.

So the proper fix is probably to delete js::Debugger::generatorFrames altogether, and instead extend CrossCompartmentKey with a new kind of key and just use crossCompartmentWrappers to associate AbstractGeneratorObjects with their Debugger.Frame counterparts.

Tragically, this seems not to be possible. The CCW tables are not ordinary weak maps. The CCW table serves to ensure a unique wrapper per referent, and to track live cross-compartment edges, but there's no reason to keep a CCW alive if nothing in its compartment refers to it --- in fact, since we want our conservative estimate of cross-compartment edges to be as accurate as possible, we would like unreferenced CCWs to be dropped as often as possible. Dropping CCWs is undetectable, since CCWs never carry interesting characteristics of their own.

The map from referents to Debugger.Objects, in contrast, must hold Debugger.Objects alive for as long as the referent and the owning Debugger are alive, like a traditional weak map. The user can place their own properties on a Debugger.Object, and then expect to find them there later if the Debugger encounters the same referent object again, so dropping a D.O while its referent and owning Debugger were still alive would be observable.

However, parallel entries in CCW tables are necessary, because the GC uses them to build zone groups, so this bug report is still valid - it's just the suggested fix that is invalid.