d at domenic.me (2015-07-07T01:36:50.903Z)
If WeakSets were iterable, then any such optimization would be observable and therefore disallowed. It is precisely the unobservability of GC that give us the freedom to engage in such transparent optimizations. The platform can certainly provide itself with internal iterable WeakSet-like collections for its own internal and unobservable purposes. If we're talking about an unobservable optimization internal to the platform, then why is the non-iterability of externally visible WeakSets an issue? Is there currently some observability issue I am missing?
If WeakSets were iterable, then any such optimization would be observable and therefore disallowed. It is precisely the unobservability of GC that give us the freedom to engage in such transparent optimizations. The platform can certainly provide itself with internal iterable WeakSet-like collections for its own internal and unobservable purposes. If we're talking about an unobservable optimization internal to the platform, then why is the non-iterability of externally visible WeakSets an issue? Is there currently some observability issue I am missing? On Tue, Jun 16, 2015 at 7:53 PM, Caitlin Potter <caitpotter88 at gmail.com> wrote: > It sounds like this is discussing the implementation in V8, unless it’s > done similarly in other engines. Possibly it’s talking about a polyfill > mechanism that might be used in compile-to-js implementations that target > older browsers. > > V8’s template map is a Map with smi keys representing the hash of the raw > string, containing a smaller array of lists of strings which yield the same > hash (usually a single template literal) > > Unfortunately, since the Map is not tied directly to the callsite objects > (which aren’t available at parse-time when the hashing occurs), there’s no > way to store these callsites in a WeakMap, and they are never collected. If > WeakSets were iterable, this could be solved pretty easily, but these are > the tools we’ve got :( > > On Jun 16, 2015, at 10:31 PM, Mark S. Miller <erights at google.com> wrote: > > Hi Yusuke, I am not sure I understood your message. Could you show some > example code that would observe the observable difference you have in mind? > > > > On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI <utatane.tea at gmail.com> > wrote: > >> Hi forks, >> >> In ES6 spec, template site objects are strongly referenced by the >> realm.[[templateMap]]. >> So naive implementation leaks memory because it keeps all the site >> objects in the realm. >> >> However, we can alleviate this situation. >> Because template site objects are frozen completely, it behaves as if >> it's a primitive value. >> It enables the implementation to reference it from the realm weakly. When >> all disclosed site objects are not referenced, we can GC them because >> nobody knows the given site object is once collected (& re-generated). >> >> But, even if the object is frozen, we can bind the property with it >> indirectly by using WeakMap. >> As a result, if the site objects are referenced by the realm weakly, >> users can observe it by using WeakMap. >> >> To avoid this situation, we need to specially handle template site >> objects in WeakMap; WeakMap refers template site objects strongly (if we >> choose the weak reference implementation for realm.[[templateMap]]). >> But this may complicate the implementation and it may prevent >> implementing WeakMap as per-object table (it can be done, but it is no >> longer simple private symbols). >> >> Is it intentional semantics? I'd like to hear about this. >> (And please point it if I misunderstood) >> >> Best Regards, >> Yusuke Suzuki >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > _______________________________________________ > 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/20150616/4cf7ef4a/attachment.html>