Could you give an example, hopefully simple, of such a problem you can solve better with GC + weakmaps + weakrefs but without finalization, vs just GC + weakmaps ? Thanks.
On Thu, Nov 7, 2013 at 1:46 PM, K. Gadd <[email protected]> wrote: > When I talk about the importance of weak references I am *not* talking > about the importance of finalization for managing native/remote resources; > that's an important consideration but it's a separate one. When I talk > about why weak references are important, I mean for the purposes of > building large applications without creating uncollectable cycles in object > graphs. Doing this without weak references is *very* difficult in some > scenarios, and in other scenarios requires manual management of all object > lifetimes (addref/release style, or having a single lifetime owner that > 'deletes' an object on demand). > > That's the sort of obstacle that factors into a developer's choice of > language and toolset. I've seen this particular concern with ES crop up in > the past on real projects, and I've seen firsthand how difficult it is to > avoid uncollectable cycles in a language environment without any sort of > weak reference mechanism. Leaking large uncollectable cycles can have > catastrophic consequences in multimedia applications and games, where those > cycles might be retaining images or sounds or other huge game assets. > > > On Thu, Nov 7, 2013 at 9:19 AM, Terrence Cole <[email protected]> wrote: > >> On 11/06/2013 07:37 PM, K. Gadd 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?) >> >> This is a false dichotomy. At the extreme, we could simply ship a new >> builtin resource manager which has it's own GC behaviour that we can >> expose at will. Given that the sorts of resources that people want to >> use the memory GC to manage generally have very different cost and >> volume tradeoffs than memory [1], this is actually much more reasonable >> than it sounds. >> >> The real problem with weak things is that they do have a performance >> impact on the GC, even when not used. Missing weak-maps can at least be >> worked around; a slow environment cannot. >> >> -Terrence >> >> 1 - >> >> http://www.mail-archive.com/[email protected]/msg00572.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 >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > 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
