Mark S. Miller (2015-06-17T03:15:23.000Z)
Thanks. That is clarifying.


On Tue, Jun 16, 2015 at 8:12 PM, Caitlin Potter <caitpotter88 at 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 <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>
> 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
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150616/3bb53eb8/attachment.html>
d at domenic.me (2015-07-07T01:36:57.243Z)
Thanks. That is clarifying.