WeakMap not the weak needed for zombie views

Mark S. Miller erights at google.com
Sun Jul 6 09:30:48 PDT 2014


On Sun, Jul 6, 2014 at 7:47 AM, Katelyn Gadd <kg at luminance.org> wrote:

> There are some fairly recent es-discuss threads about weak references.
> I don't know if there is a consensus yet (it is very hard to tell) but
> some people like Brendan are on record that there are real use cases
> that require them. I've been pushing hard for them, along with the
> author of embind. The question is mostly whether solving those
> problems is worth the cost of exposing GC to content JS (though, if
> memory serves, there was a claim in one of the discussion threads that
> you can implement weakrefs without exposing GC - I'm not sure if that
> was an 'I've figured it out' statement or just a hypothesis).
>

I would be very curious. It seems impossible by definition. Could you (or
anyone) please try to find this? Thanks.

What I have claimed is that we can isolate the communications channel that
this provides in ways that make it a reasonable (IMO) security risk.
Perhaps this is what you are thinking of?


>
> At present I don't believe WRs will ever make it onto the open web. It
> seems like there's a huge amount of resistance to the idea that is
> never going to go away, so any application that needs them is
> best-served by an emscripten-style heap and manually implemented
> collector (boehm, etc). You could probably achieve some sort of
> compromise by writing your own user-space collector that walks the
> reachable JS heap if you manage to root your JS objects correctly, but
> I suspect that would only be viable as a codegen strategy for a
> compiler targeting JS, not something you'd do by hand when writing JS.
>
> For some WR use cases you can probably do manual refcounting yourself,
> as long as you do it right - you'd want to replace the actual object
> references with a lightweight 'handle' object that forwards onto the
> real instance via a handle lookup, so that you can 'collect' the
> actual instance without requiring the handles to die.
>
> On Sun, Jul 6, 2014 at 3:17 AM, Till Schneidereit
> <till at tillschneidereit.net> wrote:
> > There is an ES7 proposal for weak references[1] that would satisfy your
> > requirements. However, at least at Mozilla there is very strong
> opposition
> > to this from people working on the memory management subsystems (i.e.
> the GC
> > and CC). It's not clear to me that their arguments have been defeated and
> > I'm not aware of any more recent discussions about this topic than those
> on
> > Mozilla's platform development mailing list[2][3].
> >
> > While I think that weak references are an important feature, I don't
> think
> > this particular use case is a good argument for them: in my personal
> > experience working with and implementing systems like you describe, weak
> > listeners were eventually deprecated and replaced by forced explicity
> > unsubscription every time. If a view is destroyed, you really don't want
> it
> > to receive any events anymore, regardless of the GC's timing. Now you
> could
> > say that in the framework's event dispatching or handling mechanism you
> can
> > detect this situation. If so, you can also just unsubscribe a
> strongly-held
> > event listener at that point.
> >
> >
> > [1]: http://wiki.ecmascript.org/doku.php?id=strawman:weakreferences
> > [2]:
> >
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/V__5zqll3zc
> > [3]:
> >
> https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/9LcqR9m5Mo4
> >
> >
> >
> > On Sun, Jul 6, 2014 at 7:00 AM, Peter Michaux <petermichaux at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> I've been reading about WeakMap in the draft. To my surprise, it is
> >> not at all what I thought it would be or what I was hoping to use. At
> >> least that is my understanding.
> >>
> >> My use case is in MV* architectures. With current MV* frameworks, a
> >> model holds strong references to the views observing that model. If a
> >> view is removed from the DOM, all other references in the application
> >> are lost to that view, but the view never stopped observing the model
> >> object, that strong reference from model to view results in a zombie
> >> view. Avoiding this means views need to have `destroy` methods that
> >> unsubscribes the view from the model. It is easy for the application
> >> programmer to forget to call a view's `destroy` method and the
> >> application leaks memory. As a result of the leak, the user experience
> >> and ultimately the reputation of the Web suffers. If a model could
> >> hold weak references to its observers, this would safeguard against
> >> accidental and inevitable application programmer forgetfulness.
> >>
> >> It appears that WeakMap cannot help solve the current MV* zombie view
> >> problem. Or did I miss something?
> >>
> >> I was expecting WeakMap to hold its values weakly and set them to
> >> undefined or delete the associated key when the value was garbage
> >> collected.
> >>
> >> Does anything exist or is coming to help solve the zombie problem?
> >>
> >> ----
> >>
> >> Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds
> >> its keys weakly. The difference compared with the ECMAScript WeakMap
> >> is that instances of WeakIdentityKeyDictionary have an iterator so the
> >> observers can be stored as the keys and still discoverable without
> >> keeping other strong references. The ECMAScript standard specifically
> >> disallows in iterator.
> >>
> >> Thanks,
> >> Peter
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140706/144350f9/attachment.html>


More information about the es-discuss mailing list