WeakMap not the weak needed for zombie views

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Mon Jul 7 01:19:44 PDT 2014

To first address the particular case of using weak maps for custom event
listeners via iteration:

I think the only relatively sane approach to iterating a WeakMap would be
to force GC whenever the WeakMap is being iterated. This would make sure
that you couldn't get references to items that are about to be
garbage-collected (and thus don't also introduce non-deterministic errors
and memory leaks for event listeners firing on disposed views). However,
this would make iterating a WeakMap potentially unbearably slow and thus
not worth using for this case. The performance hit may be tuned down by
traversing the reference tree only from the items contained in the WeakMap,
but I'm not sure if that's feasible and it would probably also make the
performance worse if the WeakMap is large enough and has a lot of resources
that are alive. Another drawback is that this would potentially lead to
abuse where for example all views would be stored in a WeakMap and then the
WeakMap would be iterated through just to force GC on the views.

On the discussion thread linked, it's also discussed that weakrefs would be
used for DOM event listeners, but I'm not exactly sure if that's a very
workable solution either. You'll basically get a weak reference locally,
but the DOM event listener will still hold a strong reference to the
function. You could of course add a weak addEventListener variant, but soon
you'd notice that you also need a weak setTimeout, setInterval,
requestAnimationFrame, Object.observe and maybe even weak promises. :/

All in all, I'm doubtful that weak references can solve the use cases
presented very well. They would basically encourage people to start
building frameworks that use weakrefs instead of lifecycle hooks only to
notice that there's some part of the platform where they need manual
reference clearing anyway. The solution, I think, is to just use frameworks
and libraries like angular and react that provide these lifecycle hooks and
take care that these hooks are triggered for you, instead of having to
manually call a destroy method.


On Mon, Jul 7, 2014 at 4:49 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/6/14, 4:11 PM, Filip Pizlo wrote:
>> My reading of the linked Mozilla discussions seems to be that some GC
>> implementors think it's hard to get the feature right
> I'm not sure how you can possibly read https://groups.google.com/
> forum/#!msg/mozilla.dev.tech.js-engine.internals/V__5zqll3zc/hLJiNqd8Xq8J
> that way.  That post isn't even from a GC implementor and says nothing
> about implementation issues!
> I think that post presents the strongest argument I know against the "use
> GC to reclaim your non-memory resources" argument, and the summary is that
> while that approach looks promising at first glance in practice it leads to
> resources not being reclaimed when they should be because the GC is not
> aiming for whatever sort of resource management those particular resources
> want.
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140707/d7714b0a/attachment.html>

More information about the es-discuss mailing list