I completely understand, but at the TC39 meeting in March 2017 I promised
Dean Tribble to get an implementation rolling to get more concrete
feedback. It is not intended to be landed as a standard, and remains as
Stage 1 (hence --harmony). My goal here is to evolve it over time / behind
a flag so people can experiment not to champion the feature.
On Monday, June 12, 2017 at 11:36:58 AM UTC-5, Daniel Ehrenberg wrote:
>
> 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]
> <javascript:>> 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] <javascript:>
> > 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] <javascript:>.
> > 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.
