Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normative: Fix the definition of liveness for WeakMap and WeakSet #121

Merged
merged 3 commits into from May 30, 2019

Conversation

@littledan
Copy link
Member

commented May 29, 2019

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".

Normative: Fix the definition of liveness for WeakMap and WeakSet
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".
@littledan

This comment has been minimized.

Copy link
Member Author

commented May 29, 2019

</p>
</li>
</ul>
If an object is not live, then the implementation may replace any

This comment has been minimized.

Copy link
@ljharb

ljharb May 29, 2019

Member

can “live” here link to the liveness section?

This comment has been minimized.

Copy link
@littledan

littledan May 29, 2019

Author Member

Doesn't it autolink due to the dfn?

This comment has been minimized.

Copy link
@ljharb

ljharb May 29, 2019

Member

oh hmm, probably so.

<emu-clause id="sec-liveness">
<h1>Liveness</h1>

An object _obj_ is considered <dfn>live</dfn> if the following conditions

This comment has been minimized.

Copy link
@mhofman

mhofman May 29, 2019

Contributor

Wouldn't an object be considered not live in these conditions?

This comment has been minimized.

Copy link
@littledan

littledan May 29, 2019

Author Member

Good catch, thanks, will need to fix this before landing.

This comment has been minimized.

Copy link
@littledan

littledan May 30, 2019

Author Member

Fixed


<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>

This comment has been minimized.

Copy link
@mhofman

mhofman May 29, 2019

Contributor

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.

This comment has been minimized.

Copy link
@littledan

littledan May 29, 2019

Author Member

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.

@mhofman

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

I'm wondering about the timing between removing WeakMap/WeakSet entries and clearing out [[Target]] field/slots.
I don't see anything preventing an implementation from removing a WeakMap entry separately from clearing a WeakRef's [[Target]] slot. If it also allows some user JavaScript to be interspersed between the 2, the object may become reachable again causing weird issues in user code.

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 IterableWeakMap example makes that assumption in the iterator:

  *[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 #weakMap is cleared before ref is, then const { value } = this.#weakMap.get(key); will cause a TypeError

@littledan

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

@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?

@littledan

This comment has been minimized.

Copy link
Member Author

commented May 30, 2019

I think the issue @mhofman is serious, and we should address it in our resolution to #105, when we figure out how to explain what guarantees we're providing. I'm landing this patch as it's really a bug fix/clarification over the text, which has this issue both before and after the patch.

@littledan littledan merged commit cc09b9d into tc39:master May 30, 2019

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
Travis CI - Pull Request Build Passed
Details

littledan added a commit to littledan/proposal-weakrefs that referenced this pull request May 30, 2019

Normative: When an object dies, all references die at once
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

littledan added a commit that referenced this pull request May 30, 2019

Normative: When an object dies, all references die at once
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.