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 1 commit
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
31 changes: 16 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,28 @@ 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 should not 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.
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we should reword this to say that losing the reference should be deterministic, as we just argued that freeing being implementation-specific is nice. (To be clear, already at fault in the original, so maybe a follow-up.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This makes sense. How about I just replace this paragraph for a concrete example, explaining why algorithms like getElementsByTagName are bad, and how you're supposed to do it, and how this ties into GC observability?


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

Expand Down