Use of registered symbols would allow observation that a `WeakMap` entry has been freed

[brad4d]

I've just had a discussion with WH to get a clear picture of his objection to allowing symbols created with Symbol.for() as WeakMap keys.

To summarize, This is the use-case that must be disallowed.

1. Symbol.for('name') gets used as a WeakMap key.
2. Later, no references to Symbol.for('name') exist other than the WeakMap key and the (virtual) GlobalSymbolRegistry entry, which don't count. So, both of these are effectively freed.
3. Still later Symbol.for('name') is called again and the result used to attempt lookup in the same WeakMap, finding nothing.

The key misunderstanding many of us have had revolves around the assumption that the GlobalSymbolRegistry entry defined in the spec must keep the Symbol.for() keys alive forever, making them effectively the same as well-known symbols that are stored on global objects. This is incorrect.

In our conversation WH explained it like this.

The VM table you're referring to is spec convenience fiction and an implementation need not implement it that way.

There are many such spec fictions. Consider a program that sits in a tight loop creating objects and not storing them anywhere. Before we had weak maps, we had no notion of object destruction, so per the spec you'd quickly exhaust memory with objects. But a realistic implementation doesn't need to do it that way and can run such a loop indefinitely. Similarly, the VM table is a spec fiction that ensures that when you call Symbol.for twice with the same string, you get the same symbol. Now imagine a program sitting in a tight loop creating consecutive unique strings "0000000000", "0000000001", "0000000002", etc., calling Symbol.for on them, but not storing the symbols anywhere. To preserve the user-visible Symbol.for semantics, an implementation need only to keep track of live symbols, so it's possible for an implementation to run such a loop indefinitely without exhausting memory. That table of all Symbol.for symbols is spec fiction.

So, I believe this proposal & its spec text need to be updated to disallow use of registered symbols as WeakMap keys.

[ljharb]

The proposal will not advance with that restriction; either all symbols or none can be WeakMap keys.

I also don't see the issue here. A registered symbol can, in general, be "freed" when it's unobservable. However, by putting it in a WeakMap, it can never be freed until that WeakMap is - a registered symbol that is weakly held remains "live" as long as the thing holding it is live. Why is this a problem?

[ljharb]

the GlobalSymbolRegistry entry defined in the spec must keep the Symbol.for() keys alive forever, making them effectively the same as well-known symbols that are stored on global objects. This is incorrect.

In other words, if you s/alive forever/observably alive forever, it seems correct to me, and allowing them to be WeakMap keys doesn't change this - it just adds a new way for them their liveness to be observable.

[brad4d]

I also don't see the issue here. A registered symbol can, in general, be "freed" when it's unobservable. However, by putting it in a WeakMap, it can never be freed until that WeakMap is - a registered symbol that is weakly held remains "live" as long as the thing holding it is live. Why is this a problem?

The point of a WeakMap is things used as keys in it are not supposed to count toward keeping them alive.
Isn't it a contradiction, then, for a symbol to be kept alive because it is used as a WeakMap key?

[mhofman]

The proposal will not advance with that restriction; either all symbols or none can be WeakMap keys.

This is a pretty strong stance. I would hope there was still a way to arrive at some kind of consensus here.

The key misunderstanding many of us have had revolves around the assumption that the GlobalSymbolRegistry entry defined in the spec must keep the Symbol.for() keys alive forever

As @ljharb mentions, the key bit is not that GlobalSymbolRegistry exists in the spec, rather that the registered symbol is observed through a WeakMap. As I explained in #19 (comment), the implication is that a registered symbol cannot be collected for as long as anything observing its liveness is itself live. Some believe that this could be a common mistake by programs that would not test for the type of symbols if not prevented by the language, and would result in preventable memory leaks, similar if we allowed string or numbers to be used as weakmap keys.

I personally see no reason to allow forgeable values as weak keys/targets, besides allowing lazy programs to shoot themselves in the foot.

[ljharb]

@brad4d no, because a registry symbol can never observably be freed, ever, already. The spec fiction is there to ensure that. In other words, it would only be in an implementation that attempted to walk the tightrope between freeing them, and keeping that unobservable, that this new difficulty would emerge.

[mhofman]

Btw, there is another reason why registered symbols being disallowed as weak keys would make sense: implementation complexity.

Since GlobalSymbolRegistry is a spec fiction, an implementation can currently trivially implement registered symbols as a sort of composite value wrapping the underlying string or number description, and compare those symbols by value instead of by unique identity like non-registered symbols. Symbol.for then simply forges a new value from the description, and Symbol.keyFor simply unwraps the underlying description value.

If allowing registered symbols as WeakMap keys, such an implementation would likely be forced to change their implementation and required to generate a unique identity for registered symbols, akin to forcing ropes.

[brad4d]

Thanks @mhofman for that succinct example.

This is in fact the point WH was trying to make, I think.
Implementations like that one are supposed to be possible for efficiency reasons.

They truly put symbols created with Symbol.for on the level with numbers, strings, booleans, etc.
You can never really "clean up" these values, because the exact same value could always be constructed again later.
This is why they are disallowed as WeakMap keys.

Allowing non-registered Symbols is OK because they can only ever be created once, so they can be safely cleaned up when no non-WeakMap-key references to them remain.

[ljharb]

I don't understand why such an implementation would need to change everything, as opposed to making a special carve-out for the subset of registered symbols that are weakly held.

[ljharb]

Separately, do any such implementations exist that could speak to these difficulties? If not, then if the spec was designed to allow a kind of implementation, but in practice there's no concrete evidence that there's any benefit to doing so, why preserve it?

[mhofman]

I don't understand why such an implementation would need to change everything, as opposed to making a special carve-out for the subset of registered symbols that are weakly held.

By special carve-out, I suppose you mean branch on the type of symbol when creating a WeakRef or WeakMap entry? That feels like significant complexity added everywhere registered symbols could be used.

Separately, do any such implementations exist that could speak to these difficulties?

I'm not sure, but @erights mentioned that's how he would have expected engines to implement registered symbols.

[ljharb]

@mhofman if we went with your suggestion of differentiating symbols between registered/well-known and "other", they'd already have to do that - so that complexity seems to be acceptable.

[mhofman]

They would only have to do that when adding the entry to the weakmap / creating the weak ref, and throw a TypeError. Here you're talking about having a parallel Map / Ref implementation for registered symbols keys/targets.

[jridgewell]

The proposal will not advance with that restriction; either all symbols or none can be WeakMap keys

I think disallowing registered symbols is a small wart that allows for a much more valuable use case to work, and so we shouldn't block just because of that. Once implementers get actual experience with how complex symbol GC becomes, we can try reopening to allow registered symbols later on.

[ljharb]

@jridgewell that's an opinion i don't share.

[acutmore]

That feels like significant complexity added everywhere registered symbols could be used.

Additional methods that would need* to branch for registered symbols if they were allowed:

• WeakSet.prototype.delete
• WeakSet.prototype.has **
• WeakMap.prototype.delete
• WeakMap.prototype.get **
• WeakMap.prototype.has **

The branch being to switch the logic to the separate internal Strong{Set,Map} used for registered symbols.

Not being a member of a JS engine implementation team, I will leave the measure of added complexity to others.

* In contrast: If registered symbols are not allowed, the above methods would not necessarily need to branch specifically for registered symbols. The existing code path for handling symbols could be used as the result would be the same. Though implementations may still add code to specially handle registered symbols as an optimisation (early return).

** EDIT: an implementation could store the registered symbols in the usual weakMap's internal structure. But also store hold registered-symbol strongly to avoid any optimisation that would otherwise collect it. This means that the has and get methods would not need to branch for registered-symbols and could look them up in the same way as other values.

https://gist.github.com/acutmore/8f16a8d4cf4b7b54c5956bd6eab05cfd

The following methods would have to check if a symbol is a registered symbols either way.

• WeakSet.prototype.add
• WeakMap.prototype.set
• FinalizationRegistry.prototype.register
• WeakRef constructor

And I don't think FinalizationRegistry.prototype.unregister would need to be changed for either approach. If registered symbols are allowed, then it's likely FinalizationRegistry.prototype.register would silently ignore the registration so there would be nothing to unregister. And if registered symbols are not allowed to be registered, then again there would be nothing to unregister.