Normative: Fix the definition of liveness for WeakMap and WeakSet #121
Conversation
This patch rephrases the definition of WeakMaps and WeakSets to explain their observable effects on garbage collection, rather than specifying operationally that non-live keys or members are deleted. It separates out a definition of "live" that can be referenced from various places. This defintion is based on earlier spec text, in terms of whether something may be "observably referenced".
| </p> | ||
| </li> | ||
| </ul> | ||
| If an object is not live, then the implementation may replace any |
There was a problem hiding this comment.
can “live” here link to the liveness section?
There was a problem hiding this comment.
Doesn't it autolink due to the dfn?
| <emu-clause id="sec-liveness"> | ||
| <h1>Liveness</h1> | ||
|
|
||
| An object _obj_ is considered <dfn>live</dfn> if the following conditions |
There was a problem hiding this comment.
Wouldn't an object be considered not live in these conditions?
There was a problem hiding this comment.
Good catch, thanks, will need to fix this before landing.
|
|
||
| <emu-clause id="sec-weakmap"> | ||
| <h1>WeakMap Objects</h1> | ||
| <p>WeakMap objects are collections of key/value pairs where the keys are objects and values may be arbitrary ECMAScript language values. A WeakMap may be queried to see if it contains a key/value pair with a specific key, but no mechanism is provided for enumerating the objects it holds as keys. <ins>There is no way for ECMAScript programs to observe the presence of a key in a WeakMap without a reference to that key. This implies that, if an object is not live, and it is present as a WeakMap key, then the implementation may unobservably remove the key-value pair from the WeakMap.</ins> <del>If an object that is being used as the key of a WeakMap key/value pair is only reachable by following a chain of references that start within that WeakMap, then that key/value pair is inaccessible and is automatically removed from the WeakMap. WeakMap implementations must detect and remove such key/value pairs and any associated resources.</del></p> |
There was a problem hiding this comment.
This does seem to relax the existing requirement that unreachable keys and associated value must be removed:
WeakMap implementations must detect and remove such key/value pairs and any associated resources.
the implementation may unobservably remove the key-value pair from the WeakMap
Of course the removal was unobservable before Weakrefs, but a non-collecting engine may now be compliant when it wasn't before.
There was a problem hiding this comment.
Yes, this relaxes the requirement's wording, but the effect is observably equivalent. I don't think the previous wording was really optimal, and I am proposing this change, as long as we are cleaning up the definitions around liveness.
|
I'm wondering about the timing between removing WeakMap/WeakSet entries and clearing out [[Target]] field/slots. One way to solve this may be to include the removal of WeakMap/WeakSet entries in the same execution section that clears out [[Target]] field/slots? Edit: For example the *[Symbol.iterator]() {
for (const ref of this.#refSet) {
const key = ref.deref();
if (!key) continue;
const { value } = this.#weakMap.get(key);
yield [key, value];
}
}If |
|
@mhofman This is a good question. I'm not sure how to word banning this revival. Isn't this an issue just with bunches of WeakRefs, not necessarily involving WeakMaps? |
This patch rephrases that logic path into an imperative algorithm, which is described to behave atomically. The PR attempts to resolve the issue documented in tc39#121 (comment) Related issue: tc39#105
This patch rephrases that logic path into an imperative algorithm, which is described to behave atomically. The PR attempts to resolve the issue documented in #121 (comment) Related issue: #105
This patch rephrases the definition of WeakMaps and WeakSets to
explain their observable effects on garbage collection, rather
than specifying operationally that non-live keys or members are deleted.
It separates out a definition of "live" that can be referenced from
various places. This defintion is based on earlier spec text, in
terms of whether something may be "observably referenced".