Private Slots

Brendan Eich brendan at
Tue Jan 15 13:56:07 PST 2013

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.

But the cost of allocating a WeakMap per object that wants private 
properties, and then GC'ing it promptly per the guarantee, is the main 
issue. When you need a WeakMap, this cost must be born. When you just 
need private properties (pace Kevin on "need"), the allocation and the 
GC mark/sweep overhead should not be imposed lightly.

Another issue, as mentioned: property access performance with private 
symbols (or unique/public ones) will be much better, out of the gates. 
Not a GC issue, just repeating so it doesn't get lost.

> The major difference is how people will use each tool. From experience 
> in OO programming, most objects have a finite set of properties 
> determined at object creation time. It's true even in JavaScript where 
> objects are bags of properties. This allows to write "stable" code 
> (you can write "o.find()" assuming there is a find property which 
> value is an function). If people were creating eratic objects, writing 
> what I call "stable" code would be a much more complicated exercise. 
> This "cultural" use of objects is what makes optimizations like 
> Shape/HiddenClass possible.

Yup, I should have read ahead.

> WeakMaps, on the other hand, are used as a maps key'ed on objects, 
> with the convenience that you don't need to clean the map when the 
> object is about to disappear. There is a assumption that when you 
> create a new weakmap, its use is largely independent of previous 
> weakmaps and it's unlikely 2 weakmaps will have the same set of 
> objects, so engines are unlikely to perform optimizations combining 
> different weakmap storages so that the values of the same key will be 
> close to one another or something like that.
> WeakMap and Symbols each corresponding to a given patterns of use of 
> (object, object) -> value mappings. Although a unique feature could be 
> used to emulate the other, it would be very hard for an implementation 
> to optimize one feature for 2 patterns.
> If anything, choosing one feature over the other is a way to tell your 
> coworkers and the JS engine which pattern you want to use.

Good point. There is inherent complexity in having two things, with some 
overlap. I don't see it as fatal. I think Kevin's stronger point is 
YAGNI re: high-integrity privacy, outside of SES use-cases.

But SES support is a goal of Harmony and ES6.


More information about the es-discuss mailing list