Dependency on Symbols as WeakMap keys proposal

[Jamesernator]

So for the new ShadowRealm to be able to handle GC across the realm boundary we need the symbols as WeakMap keys, as otherwise we are unable to provide a collectable identity for an object in a ShadowRealm.

But we have a situation at the moment where implementers seem to be willing to implement this design of ShadowRealm and the API is even at Stage 3. However the symbols-as-WeakMap-keys proposal is still at Stage 2 and I don't see as much activity on it so it's hard to tell if there is agreement that that will ship also if ShadowRealm does.

Do we consider this dependency on symbols-as-weakmap-keys as a problem? Or would shipping ShadowRealm without that proposal still be acceptable?

[ljharb]

Why? You can make a Map of Symbols to WeakRefs, and put the object in the weakref.

[Jamesernator]

Why? You can make a Map of Symbols to WeakRefs, and put the object in the weakref.

See this comment in the original idea for primitives only (+function wrappers), @erights may need to clarify what situations become uncollectable.

[mhofman]

handle GC across the realm boundary we need the symbols as WeakMap keys

Could you clarify why?

The object graphs of multiple shadow realms are fully entangled through the closures that any wrapped callable exotic has in its context, so it's not an implementation requirement.

From a program perspective, you actually don't need any WeakMap or WeakRef to implement a membrane on top of the callable boundary as shown by salesforce/near-membrane#178. However it would greatly simplify the design of such membranes to be able to directly pass primitive placeholders representing objects which can be used in WeakMaps, like more traditional membranes.

[Jamesernator]

Could you clarify why?

Why? You can make a Map of Symbols to WeakRefs, and put the object in the weakref.

See this comment in the original idea for primitives only (+function wrappers), @erights may need to clarify what situations become uncollectable.

It's possible this doesn't apply anymore, but I recall seeing a few people assuming that symbols as weakmap keys would work in #289 and #299 so I was mostly raising this issue as I assumed that they would be still be required.

From a program perspective, you actually don't need any WeakMap or WeakRef to implement a membrane on top of the callable boundary as shown by salesforce/near-membrane#178. However it would greatly simplify the design of such membranes to be able to directly pass primitive placeholders representing objects which can be used in WeakMaps, like more traditional membranes.

As membranes are the main reference to symbols as weakmap keys in the aforementioned issues, this is possibly a non-issue then. The implementation of that is a bit much for me to be able to follow, but does that guarantee collectability of cross-realm cycles?

[mhofman]

collectability of cross-realm cycles

Engines have a single GC per agent (and I actually hear they're moving to a single GC per agent cluster), which means they're able to identify direct cycles across realms, and they already do today.

A membrane implementation using the callable wrapper trick in effect creates a reference from a proxy representative in one shadow realm to the real target object in the other realm, and a reference to the proxy from the other realm so that it can be "selected" by the boundary. WeakMap are in fact used to remember which selection / "pointer" wrapped callable to use for each exported object. All that to say it's possible to implement a membrane without anchoring anything in any realm's root, so a single GC can perform cycle detection.

[Jamesernator]

I'm gonna close this as implementations are starting to appear for both symbols as weakmap keys and shadow realms, so people should be able to use them together to implement object tracking fairly easily.