Private Slots

Mark S. Miller erights at google.com
Tue Jan 15 14:37:32 PST 2013


On Tue, Jan 15, 2013 at 2:27 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Mark S. Miller wrote:
>>
>> On Tue, Jan 15, 2013 at 1:56 PM, Brendan Eich<brendan at mozilla.com>  wrote:
>>>
>>> David Bruant wrote:
>>>>
>>>> In theory, private symbols should have the same GC issues than WeakMap.
>>>> Consider:
>>>>
>>>>      var o = {}, o2 = {};
>>>>      for(var i=0, i<1000, i++){
>>>>          let s = new Symbol(true /*private*/);
>>>>          o[s] = o2[s] = i;
>>>>      }
>>>>
>>>> Here, private symbols are created, properties are added. Because of
>>>> let-locality, every symbol can be GC'ed, because at the end of the loop,
>>>> no
>>>> one can ever access any of the symbols. The equivalent of the WeakMap GC
>>>> property would want properties in o and o2 to be removed too. I'm
>>>> willing to
>>>> bet this will never happen in any JS engine.
>>>
>>> This is not the "GC issue" that was raised, precisely because WeakMap
>>> does
>>> make no-cyclic-leak guarantees that Symbols as used in your example do
>>> not.
>>>
>>> So Symbols could have the leak problem that WeakMaps cure, and that is
>>> another issue.

The hint I spoke of would suggest to the engine that it's ok for this
weakmap to have this same leak, i.e., to allow the (wm,key)=>value
association to outlive wm, the weakmap.


>
>
> This stuff still stands.
>
>
>>> But the cost of allocating a WeakMap per object that wants private
>>> properties,
>>
>>
>> I'm not following this. Why would you allocate more WeakMaps than you
>> would have allocated private symbols? If the goal is per-class
>> privacy, which is the private symbol use case, you'd allocate one
>> WeakMap per field per class just as you would have with private
>> symbols.
>
>
> The savings comes from prototypal inheritance. Given one class with 2
> private methods, you need only 2 symbols. These are flat frozen objects,
> maybe even internally more efficiently represented.
>
> Given one class with 2 private weakmaps, you need those two weakmaps, indeed
> also allocations -- but then they must expand to index every instance of the
> class!

There are two obvious implementations of weakmaps. The one you imagine
above is indeed the one more naturally suggested by its semantics,
where the (wm,key)=>value associations are stored as key=>value
associations within wm. The other, which corresponds to how you expect
to implement private symbols, is to store wm=>value associations
within key. The first is better when key typically outlives wm. The
second is better when wm typically outlives key. In the absence of the
hint, it is not clear which would be more common. The hinted case, if
we support the hint, should always use the second representation. Then
there's no storage difference between the hinted wm story and the
private symbol story that I see. Of course, other differences remain,
but let's settle this one first.


>
> /be



--
    Cheers,
    --MarkM


More information about the es-discuss mailing list