On Tue, Jun 13, 2017 at 9:37 AM, Bradley Farias <[email protected]> wrote:
> > What sort of feedback are you looking for? > > I'd ask Dean, not me. > > > Do you think landing such a patch will lead to better feedback than > keeping this code in a branch? > > Yes, it was a struggle to get the v8 build built on a machine, the build > process is somewhat difficult while it is on a custom branch. Also, > increased complexity once someone wants Node build which is still using GYP. > The tradeoff with maintaining purely-experimental code in mainline is that it's a cost all V8 developers have to bear, rather than only the developer concerned with the feature. See https://github.com/v8/v8/wiki/Feature%20Launch%20Process#experimental-implementation for some details about V8's policies around experimental features. For this specific case, the fact that this is only at a very early stage of standardization, and for the reasons Dan mentioned in his first response to you, I think it's unlikely WeakRefs are going to pass the bar described in https://github.com/v8/v8/wiki/Feature%20Launch%20Process#technical-considerations . Have you looked into implementing this feature via the public API? That would be a path that would still allow experimentation by authors, but without imposing a burden either on you as the feature implementer or upon the V8 codebase. - Adam On Tuesday, June 13, 2017 at 8:43:03 AM UTC-5, Daniel Ehrenberg wrote: >> >> What sort of feedback are you looking for? Do you think landing such a >> patch will lead to better feedback than keeping this code in a branch? >> El 13/6/2017 15:34, "Bradley Farias" <[email protected]> escribió: >> >>> 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]> >>>> 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. >>> >> -- > -- > 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.
