I cannot implement the feature to spec purely w/ the public api in v8.h, though https://github.com/TooTallNate/node-weak comes somewhat close using persistents.
On Tuesday, June 13, 2017 at 12:19:24 PM UTC-5, Adam Klein wrote: > > On Tue, Jun 13, 2017 at 9:37 AM, Bradley Farias <[email protected] > <javascript:>> 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] <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.
