Thanks. That is clarifying.
On Tue, Jun 16, 2015 at 8:12 PM, Caitlin Potter <caitpotte...@gmail.com> wrote: > 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> > 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> 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> >> 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 >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > > > -- > Cheers, > --MarkM > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss