What is the status of Weak References?

Brandon Benvie brandon at brandonbenvie.com
Fri Feb 1 06:53:58 PST 2013

It's not possible to polyfill or emulate weak references (or WeakMaps for
that matter) in JS without completely disengaging from using the host JS
engine's object model. In Continuum, for example, I can get close but not
quite all the way to emulating WeakMaps using a meta-interpretive approach
to the object model (each object in the VM corresponds to one or more
objects in the host engine). Eventually I'll switch to switching to using
my own typedarray-backed heap with a GC in order to fully realize the
semantics of WeakMaps.

On Fri, Feb 1, 2013 at 5:06 AM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 31/01/2013 22:48, Kevin Gadd a écrit :
>  I ask this because the lack of weak references (or any suitable
> substitute mechanism) comes up regularly when dealing with the
> challenge of porting native apps to JavaScript, and it leads people to
> consider extremely elaborate workarounds just to build working
> applications (like storing **all** their data in a virtual heap backed
> by typed arrays and running their own garbage collector against it).
> If there is really a firm reason why this must be so, so be it, but
> seeing so many people do an end-run around the JS garbage collector
> only to implement their own **in JavaScript** makes me wonder if perhaps
> something is wrong. The presence of WeakMaps makes it clear to me that
> solving this general class of problems is on the table.
>  I don't understand the connection between the lack of weak references and
> emulating a heap in a typed array.
>  Historically the lack of weak references has resulted in various
> solutions in libraries like jQuery specifically designed to avoid
> cycles being created between event listeners and DOM objects. Many of
> these solutions are error-prone and require manual breaking of cycles.
>  Garbage collectors have evolved and cycles aren't an issue any longer,
> weak references or not.
>  But on the
> other hand I've been told in response to this question before that
> TC39 has a general policy against features that allow garbage
> collection to be visible to applications.
>  I'm not part of TC39, but I'm largely opposed to anything that makes GC
> observable. It introduces a source of non-determinism; that is the kind of
> things that brings bugs that you observe in production, but unfortunately
> didn't notice and can't reproduce in development environment. Or if you
> observe them when running the program, you don't observe it in debugging
> mode.
> David
> _______________________________________________
> 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/20130201/5d79d513/attachment-0001.html>

More information about the es-discuss mailing list