Interesting impact on other specifications

@ricea

whatwg/streams#932 by @ricea brings up an interesting situation. I'm curious what the champions have to say about this, although I don't anticipate any changes to the weak refs proposal because of it.

The summary is:

A spec is written so that spec-created object y holds on to a user-provided object x indefinitely
However, after calling y.close(), y will never use x.
Thus, it is currently unobservable whether or not an implementation allows x to be GCed before y.

With weak refs, this of course becomes observable. Thus once weak refs are introduced, the spec as-written mandates that x never be GCed before y.

In reaction to this, the spec author should probably change y.close() to null out the internal reference to x explicitly. Then browsers will again be allowed to collect x before y and free up some memory, while still conforming to the spec.

Generalizing, the tricky parts of the situation are:

Spec authors have to be more aggressive about nulling out internal references than they were before, when such references were unobservable. (Assuming they want to avoid mandating unnecessary memory usage.)
Implementers now have to be exact in following specs' recommendations on nulling out (or not) an internal reference, since doing so is now observable.
There are probably many divergences today in memory management strategies between browsers on various APIs of this sort, which may need to be audited now that the strategy is becoming observable.

Specifying the semantics of gc is hard. At http://web.archive.org/web/20160318124045/http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics I suggest an upper bound on what may be collected (i.e., a lower bound on what must be retained):

Our safety requirements allow some reachable objects to be collected as well, so long as the garbage collector can ascertain that they will never be reached.

See the three papers linked at the bottom of that page. They are good but I no longer remember them in any detail.

Hmm. I doubt this is really a problem. The web platform doesn't specify a GC algorithm that has a mark phase and unconditionally visits every internal field. x can be collected, even though y is specified to have a field that points to it, because x is unreachable in the plain English sense—it can't be reached. The field is dead.

Interestingly, this specification itself faces these liveness issues, in #66. Overall, though, I don't think we should take any action here on the specification side, since spec datastructure reachability already isn't the definition of reachability by garbage collectors.

For example, the following code sample shouldn't hold up bigData's collection for the whole activation frame to go away:

(function() { 
  const bigData = { /* lots of stuff */ };
  const group = new FinalizationGroup(iterator => {
    for (const item of iterator) console.log(`collected ${item}`);
  });
  group.register(bigData, "data");
  setTimeout(() => console.log("timeout"), 1000);
})();

This should be allowed to print out:

collected data
timeout

However, in terms of spec data structures, the environment record which points to bigData is still referenced from the function, and the environment record is referenced when looking up console.

There's still a practical issue about potential compatibility issues where one engine has a more precise definition of liveness than another. But JavaScript contexts are already a very present case of this, where developers already report out-of-memory issues that exist on some browsers and not others, which can be traced back to diverging issues of liveness. The details of streams' liveness will be much smaller in magnitude than closures, but at the same time, there's no clear path to compatibility in the closure case.

Anyway, maybe we should mention this to the TAG and get their take as well. We should document clear guidance for specification authors about what all this means.

Normative: Refine definition of reachability

Reopening this issue to discuss possibilities for spec notation for weak references; see #168 (comment) .

Navigation Menu

Repository navigation

Interesting impact on other specifications #31

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Interesting impact on other specifications #31

Description

Activity

erights commented on Jun 19, 2018

jorendorff commented on Oct 23, 2018

littledan commented on Apr 17, 2019

littledan commented on Apr 17, 2019

littledan commented on Nov 23, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions