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.
