Template site objects and WeakMap

Caitlin Potter caitpotter88 at gmail.com
Wed Jun 17 03:12:39 UTC 2015


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 <erights at 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 <caitpotter88 at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
>> 
>> 
>> 
>> 
>> -- 
>>     Cheers,
>>     --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss <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/bf860779/attachment-0001.html>


More information about the es-discuss mailing list