Hi Bradley,
Interesting to see this work. I personally haven't reviewed it
thoroughly, but I wanted to mention a piece of context for this
proposal based on feedback from discussions I've had with some garbage
collection implementers.
tl;dr The claim is: WeakRefs cause challenges in maintaining
implementations, for interoperability, and encourage questionable
programming models. The mitigations in this spec aren't enough.
Implementations are interesting, but this objection is not based on
how implementable the proposal is (it seems pretty implementable and
well-defined). In some more detail, the issues are:
- Although some WeakRef use cases sound reasonable, many cases have to
do with freeing externally held resources. And although doing that as
a last-resort fallback path isn't bad, the existence of WeakRefs
encourages *depending on* this sort of resource freeing in the normal
case. Reportedly, this is common in the Java ecosystem, and is the
bane of Java GC implementers. The typical bug is, "my resource didn't
get collected promptly enough!" or "my resource didn't get collected".
- Different JavaScript engines, and different versions of the same
engine, use different heuristics for collection, and therefore have
different timings for when things are collected. V8 has been playing
with these timings a lot recently, and the result has been much lower
memory use and shorter pause times (at the same time! The V8 GC team
is pretty amazing). However, sometimes these manipulations lead
objects to be alive for longer or shorter amounts of time. There's
always a tension, since collecting things more eagerly takes up CPU,
and collecting them more lazily takes memory, so progress over time as
GCs get better is not strictly in the 'shorter' direction. When things
move in the 'longer' direction, programs which have gotten used to the
shorter time are likely to experience resource exhaustion. Or, you
might write your program against one JS implementation which has one
timing, and observe it to take much longer in another one.
- There are certain cases where memory is kept alive for much longer
than one would expect, or forever. For example, in V8, if you have the
following code:
```
var store_g;
(function() {
var a = ...
var b = ...
function f() {
// use a
}
function g() {
// use b
}
window.g = g;
})();
```
In this case, the value of `a` will be kept alive until the global
reference to `g` is deleted, even if the code doesn't contain any
reference to f outside the IIFE, eval, etc. This is a pretty
fundamental thing about the way V8 stores closures. Maybe it'll be
changed in the future, but it will be a big project. There are also
some more subtle cases with storing information for deoptimization,
etc.
I'm sure other engines that aren't V8 have other cases analogous this
where it's difficult to realize that certain objects are dead, but I
don't know the details. These cases are likely *different* between
different implementations,since they're a result of the detailed way
that everything is represented in memory. Without WeakRefs, the worst
thing that can happen is that your program runs more slowly/takes more
memory because the things are not collected. Bad, but somehow a
scoped-down problem. With WeakRefs, on the other hand, you can *leak
external resources* in a way which is not consistent across multiple
browsers.
This proposal tries to mitigate these sorts of concerns in a couple
ways, but they don't get to the heart of the matter.
- One nice thing about the proposal is that it's a post-mortem WeakRef
system, which bans reviving objects by construction. This is great--it
would've been another nightmare on top to implement this revival and
work out the bugs; since it's not proposed, I didn't go into more
details about the disadvantages of such a system.
- For timing, the proposal pushes timing a bit later, to after
microtasks run. Well, that gets you a little bit better, but it
doesn't help if the differences may be several seconds rather than
tens of milliseconds difference, or if some things might never be
collected.
- For compatibility, the proposal makes it very clear that the
specification does not expect any particular sort of thing, or that
callbacks are ever called at all. It's great that it makes this point
loud and clear, but I'm not convinced that this will have enough of an
impact on real users--if the feature's out there, people may use it,
construct fragile websites, and still expect browsers to fix the
issues. Browser have to fix tons of bugs about compatibility or
meeting expected behavior even when specs say very strongly not to do
things. Just look at the HTML5 parser spec, or JS's Annex B. In
practice, programmers are likely to figure out some rough estimate of
what browsers do, and strongly depend on things continuing to work
that way, no matter how much we yell at them not to.
For these reasons, I'd expect pretty strong pushback from JS engine
owners, even if someone steps up to contribute an implementation in
multiple VMs.
Dan
On Wed, May 31, 2017 at 4:09 PM, Bradley Farias <[email protected]> wrote:
> I have made a prototype of the WeakRef proposal for TC39 while they try to
> play around with an implementation before moving forward.
>
> The change set is rather large but at
> https://codereview.chromium.org/2915793002 .
>
> I am seeking a review and any recommendations on how this could change. Some
> things like timing are not clearly defined yet in the proposal so I was
> using the same microtask queue as Promises.
>
> --
> --
> v8-dev mailing list
> [email protected]
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
