domenic at domenicdenicola.com (2013-08-09T20:13:17.984Z)
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 http://wiki.ecmascript.org/lib/exe/fetch.php?media=meetings:relationships.pdf 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.
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 < http://wiki.ecmascript.org/lib/exe/fetch.php?media=meetings:relationships.pdf> 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 > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130805/3d44146d/attachment.html>