On Wed, Nov 6, 2013 at 7:37 PM, K. Gadd <[email protected]> wrote: > Generally speaking, all the discussions on this list about WRs so far have > not suggested that there is any way to introduce WeakRefs without making GC > behavior observable in some fashion. WeakRefs functionally make GC > observable because when you try to get at the target of the weakref, you > either get it or you don't. Once you introduce the ability to get back > 'null' when asking for the target of a WR (or any similar failure case), > you can use that to determine things about GC behavior. > > If you somehow eliminate this weakness, WRs no longer solve the problems > they are intended to solve. Or at the least, they solve only a small > reduced subset of the problems solved in real software via the use of weak > references. Being able to access the target of the WR (and have this > operation fail) is core to their value (even if finalization notifications > are also used quite often). > > I've already argued in the past about why weak references are important, > and why not having solutions for those problems will kneecap the > development of web applications by either preventing certain types of > software from running in the browser, or forcing implementers to write > their own GCs (or entire runtime environments) inside the browser, as is > done with environments like emscripten and native client. Once that becomes > the solution, the ES spec is irrelevant for those applications because they > have had to abandon the language. While the risk of something like this > happening is still relatively low, the risk increases over time as more > people begin seriously considering solutions like emscripten and nacl - > we're starting to see companies ship real products using them already. If > this spreads to popular reusable libraries (physics libraries, rendering > libraries, etc), there's a risk that those libraries will pull new > applications out of the ES realm because it's not possible to use those > libraries without abandoning ES in favor of a custom GC/runtime environment. > > Based on the conversations thus far, a choice just has to be made between > the two downsides: exposing some amount of GC internals, or making it > impossible to write some subset of applications in ES. It's possible that > exposing GC semantics has such catastrophic security consequences that > ruling those applications out is merited. It's also possible that > workarounds can be applied to reduce the harm of GC visibility (I think in > the past someone - maybe Mark? - suggested that disabling cross-realm WRs > would mitigate the damage considerably?) >
Yes, that's the idea. https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html > > On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt <[email protected]> wrote: > >> On Nov 6, 2013, at 3:14 PM, Rick Waldron <[email protected]> wrote: >> >> >> >> >> On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola < >> [email protected]> wrote: >> >>> Thanks Mark for the education, especially on the pre- vs. post-morterm >>> finalization distinction. I don't think I was specifically advocating for >>> pre-mortem in my OP, since I didn't really understand the difference :P. >>> Post-mortem finalization sounds quite reasonable. What do people think of >>> introducing it into ECMAScript? >>> >> >> This may be a naïve question, but how would the handler know which >> object/weakref had been gc'ed? >> >> You wouldn’t :) >> >> I’m kind of anti-finalisers in JS for all of the reasons people have >> raised - they are extremely hazardous, expose non-deterministic behaviour, >> etc >> >> Given our general desire to avoid exposing internal GC semantics, and the >> difficulty in defining observable GC behaviour (I suspect this would be a >> non-starter in any case), I can’t see any specification that would allow >> useful finalisers or WeakRefs. >> >> If MarkM has an idea for WeakRefs that don’t leak observable GC behaviour >> i’d love to hear, but in general i’m opposed to both them and finalisers :-/ >> >> —Oliver >> >> Rick >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
