WeakMap, clear, and, inverted implementations

Mark S. Miller erights at google.com
Mon Aug 5 12:49:07 PDT 2013

On Mon, Aug 5, 2013 at 11:45 AM, Brendan Eich <brendan at mozilla.com> wrote:

> Allen Wirfs-Brock wrote:
>> Regarding, "it comes clear that an implementation of WeakMap should
>> always keep associations on the key object...".  I don't agree with that
>> assertion at all as it ignore the caching use case.
> Yup. Indeed one of those caching use-cases is for membranes, where
> soft-fields do not work.

WeakMaps mean that after b at r = v (or r.set(b, v), that v is reachable if
both b and r are reachable. If the association is stored on b and the
collector first notices that b is unreachable, then it can collect v
conventionally. If the collector first notices that r is unreachable, then
to collect v while b is still live it would need to resort to ephemeron
collection. And vice versa. In the absence of WeakMaps, all joins in the
reference graph are GC disjunctions. WeakMaps introduce conjunctions.
Conjunctions are symmetric, so whereever you put the association, you make
one relative lifetime relationship cheap at the cost of making the other
one expensive. Which choice then depends on use cases and expectations.
That's what the gc analysis in <
is about.

For membranes, the WeakMaps last as long as the membrane in unrevoked.
During this time, references to many transient objects pass through the
membrane. Storing the associations in the membrane's WeakMaps makes
revocation cheap but normal operation expensive. Storing the associations
in the key objects makes normal operation cheap but revocation expensive
which is what I've wanted every time I've used a membrane.

For use for private fields of classes, the instances *cannot* outlive the
relationship (WeakMap), and so, if we store the relationship in the keys,
ephemeron collection will never be needed for that use case.

Let's look at some caching examples. I bet that for the typical
WeakMap-based cache, the cache will outlive many of its keys, and so we'll
do better by keeping the associations in the key objects.

> Mark, I'm thinking of not only Mozilla and TomVC code, but this:
> http://wiki.ecmascript.org/**doku.php?id=harmony:proxies&s=**
> proxy#garbage_collection_**behavior<http://wiki.ecmascript.org/doku.php?id=harmony:proxies&s=proxy#garbage_collection_behavior>
> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130805/3d44146d/attachment.html>

More information about the es-discuss mailing list