That example looks to me like it could be implemented with WeakMap instead of WeakRef. Am I missing something?
On Thu Nov 07 2013 at 2:43:45 PM, K. Gadd <k...@luminance.org> wrote: > I'll try and restate an example I used before. > > Let's say you're building a somewhat simple tab-based application, where > each tab represents a different 'mode'. In this case, you need a higher > level coordinating object that manages the tab bar, and it needs to own > references to all of the active modes in order to manage the tabs. > Similarly, each mode may need to have a reference to the coordinator in > order to interact with it - like by setting the title of the tab, or > opening a new tab containing another mode - and it may need to have > references to other modes in order to communicate (like if one tab opens a > tab containing related information). > > In a model like that, you can trivially end up with object cycles. All the > references (going in every direction) are strong, so to successfully > collect a mode you need to ensure that every reference to it from live > objects is released. This is problematic because it means that, for example: > > If Mode A opens a new tab containing Mode B, and Mode A wants to respond > to things happening in Mode B, Mode A now has to register some sort of > event listener on Mode B. This means that Mode A and Mode B have now formed > a strong cycle: Mode B's event listener list contains a strong reference to > Mode A (to fire the event notification), and Mode A has a strong reference > to Mode B in order to be able to respond to those events. > > Now, if you close Mode B, the coordinator gets rid of the tab and drops > its strong references to Mode B - the tab is 'gone' - but there's no > trivial way to ensure that everyone else holding a reference to it is dead. > If multiple tabs interact in this way it's possible for a huge graph of > objects to be hanging off one live tab. Eventually, if you close enough > tabs you might 'free' the graph, but if you aren't careful the coordinator > itself can end up keeping dead tabs alive, with things like event listener > lists. > > In the real apps I've worked on like this, the solution was some form of > weak references - making event listeners own weak self-references instead > of strong self-references, so that in normal circumstances event > subscriptions expire along with the subscriber, along with using weak > references directly in cases like 'tab a spawns tab b' in order to ensure > that you aren't keeping an object alive just to monitor it. > > IIRC, cycles like this are already common in some DOM scenarios, where > event subscription and such result in big graphs of objects hanging off a > single live object? I've certainly run into it in a few cases, where an > event listener hanging off an <audio> element caused a huge graph of > objects to leak, and I had to manually remove the event listeners at an > appropriate time (and finding an appropriate time can be difficult!) > > > On Thu, Nov 7, 2013 at 2:33 PM, Mark S. Miller <erig...@google.com> wrote: > > 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 <k...@luminance.org> 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 <tc...@mozilla.com> 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/dev-tech-js-engine-internals@lists.mozilla.org/msg00572.html > > > On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt <oli...@apple.com> wrote: > > > >> On Nov 6, 2013, at 3:14 PM, Rick Waldron <waldron.r...@gmail.com> > wrote: > >> > >> > >> > >> > >> On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola < > >> dome...@domenicdenicola.com> 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 > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > >> > >> _______________________________________________ > >> es-discuss mailing list > >> es-discuss@mozilla.org > >> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > > > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > -- > Cheers, > --MarkM > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
