Open Bug 1494121 Opened 6 years ago Updated 2 years ago

Check whether all Debugger-related CrossCompartmentKey variants are really needed

Categories

(Core :: JavaScript Engine, enhancement, P3)

Product:
Core
Component:
JavaScript Engine
Type:
enhancement

Tracking

()

People

(Reporter: jorendorff, Unassigned)

References

(Blocks 1 open bug)

Details

We have special CrossCompartmentKeys for entries in the Compartment's WrapperMap that represent Debugger.Objects. We need it because each Debugger.Object has a ⚡Dirëct Pøinter⚡ to its referent, compartment boundaries be damned. We also have special CrossCompartmentKeys for Debugger.Source, Debugger.Environment, and so on: <https://searchfox.org/mozilla-central/rev/881a3c5664ede5e08ee986d76433bc5c4b5680e6/js/src/vm/Compartment.h#33-37> Those would be unnecessary, if instead of using setPrivateGCThing to store the cross-compartment edge, we can just use the normal CCW machinery. So, for example, instead of a Debugger.Source object having a private slot that points directly to a debuggee ScriptSourceObject, it would have a reserved slot that points to the debugger-compartment CCW whose target is the ScriptSourceObject. Can we do that? (The reason we don't do this for Debugger.Object is that the referent of a Debugger.Object can be a cross-compartment wrapper whose target is in a non-debuggee compartment. The normal CCW machinery would make a mess of that. I'm saying I don't think Source objects, scripts, or the other referent types have that special case.)
How could we ensure that a debugger-compartment CCW for the referent (ScriptSourceObject, environment object, whatever) would be a fully transparent wrapper? Or, it doesn't matter because we'd just always UnsafeDereference it before using it from the C++ code?
Flags: needinfo?(jorendorff)
The latter. I think UncheckedUnwrap would be fine, though a CheckedUnwrap should always succeed too.
Flags: needinfo?(jorendorff)
What's the overhead on UncheckedUnwrap? If that's acceptable, then making those pointers less magic seems like the right approach. I guess we must already dealing with the fact that the ultimate referent is in a separate compartment.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.