> 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. 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] <javascript:>> > 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] <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.
