It’s not related to observability, this just isn’t used currently, and probably wouldn’t be much of an improvement if it were. Creating the template callsites themselves is pretty costly, and using weak references to the callsites would, in the majority of cases, mean recreating them every time they were used. So, while making the implementation more complicated, I don’t think it would be a win for performance, only for memory consumption.
> On Jun 16, 2015, at 11:05 PM, Mark S. Miller <erig...@google.com> wrote: > > 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 <caitpotte...@gmail.com > <mailto:caitpotte...@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 <erig...@google.com >> <mailto:erig...@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....@gmail.com >> <mailto:utatane....@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@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> >> >> >> >> >> -- >> Cheers, >> --MarkM >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
