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.

Sign up for GitHub

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

Update GC observability with WeakRefs #129

Merged
merged 3 commits into from
Jul 3, 2019
Merged

Update GC observability with WeakRefs #129

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
339efd0
Update GC observability with WeakRefs
littledan May 28, 2019
6d27bbb
Make example more concrete
littledan May 28, 2019
2513dbe
Feedback from David
littledan May 31, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 28 additions & 15 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ url: https://w3c.github.io/IntersectionObserver/;
type: dictionary; text: IntersectionObserverInit; url: #dictdef-intersectionobserverinit
url: https://wicg.github.io/ResizeObserver/;
type: interface; text: ResizeObserver; url: #resizeobserver
url: https://dom.spec.whatwg.org/#ref-for-concept-getelementsbytagname; type: interface; text: getElementsByTagName; for: Document
</pre>

<style>
Expand Down Expand Up @@ -81,28 +82,40 @@ object property).

<h3 id="js-gc">Do not expose garbage collection</h3>

There must not be a way for author code to deduce when/if garbage collection of JavaScript objects
has run.
Web APIs should not expose a way for author code to deduce when/if garbage collection of JavaScript
objects has run.

The reason for this is somewhat subtle. If garbage collection timing were observable, then authors
could easily write code relying on specific garbage collection timing. But this timing is almost
certainly not the same across user agents, which means the resulting code will be
Although some APIs may expose garbage collection, such as some implementations of
{{Document/getElementsByTagName}}, and the JavaScript <a
href="https://github.com/tc39/proposal-weakrefs">WeakRefs proposal</a> (which has multiple
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be worth pointing out that WeakRef is less harmful because it's explicit about its dependency on GC timing, and therefore developers are more likely to be aware of it. Whereas, if an API has something that "randomly" becomes null at some point in the future, authors are likely to be unaware that they're depending on GC timing by assuming it's non-null.

implementer support), API designers are strongly encouraged to avoid points in their own APIs that
depend on this timing.

The reason for this is somewhat subtle. The more that Web API semantics are affected by garbage
collection timing (or whether objects are collected at all), the more programs will be affected by
changes in this timing. But user agents differ significantly in both the timing of garbage
collection and whether certain objects are collected at all, which means the resulting code will be
non-interoperable. Worse, according to the usual rules of game theory as applied to browsers, this
kind of scenario could force other user agents to copy the garbage collection timing of the
original in order to create interoperability. This would cause current garbage collection
strategies to ossify, preventing improvement in one of the most dynamic areas of JavaScript
virtual machine technology.

In particular, this means that you can't expose any API that acts as a weak reference, e.g. with a
property that becomes <code highlight="js">null</code> once garbage collection runs. Such freeing of memory must
be entirely deterministic.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth keeping this example somehow, since it's a particularly clear and simple example of what it means for an API to depend on GC timing.


<div class="note">
There is some speculative discussion of exposing weak references such that their finalization is
only observable between event loop turns in this <a
href="https://github.com/tc39/proposal-weakrefs">stage 1 proposal under discussion at TC39</a>.
However, this remains contentious and does not yet have consensus in TC39 or among implementers.
</div>
In particular, this means that you shouldn't expose any API that acts as a weak reference, e.g. with a
property that becomes <code highlight="js">null</code> once garbage collection runs. Such freeing of
memory should be entirely deterministic.

For example, currently, {{Document/getElementsByTagName}} permits reusing the {{HTMLCollection}}
which it creates, when it's called with the same receiver and tag name. In practice, engines reuse
the output if it has not been garbage collected. This creates behavior which differs based on the
details of garbage collection, which is strongly discouraged. If {{Document/getElementsByTagName}}
were designed today, the advice to the specification authors would be to either reliably reuse
the output, or to produce a new {{HTMLCollection}} each time it's invoked.

The case of {{Document/getElementsByTagName}} is particularly insidious because nothing about
the API visibly relates to garbage collection details. By contrast, special APIs for this particular
purpose such as `WeakRef` and `FinalizationGroup` have their GC interaction as a specific part of
their contract with the developer.

<h2 id="api-surface">API Surface Concerns</h2>

Expand Down