Private symbols as WeakMap sugar

David Bruant bruant.d at
Wed Jan 16 12:17:08 PST 2013

Le 16/01/2013 20:27, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 16/01/2013 19:42, Brendan Eich a écrit :
>>> David Bruant wrote:
>>>> Hi,
>>>> This is an idea naturally derived of all the current discussions 
>>>> about WeakMaps and Private symbols. The proposal is easily 
>>>> summarized by these lines of code:
>>>>     var wm = new WeakMap();
>>>>     var o = {};
>>>>     o[wm] = 12 // desugars to wm.set(o, 12)
>>>>     var a = o[wm]; // desugars to wm.get(o);
>>>>     wm in o // desugars to wm.has(o);
>>>>     delete o[wm] // desugars to wm.delete(o); 
>>> You are not showing the desugaring in general:
>>> function get(o,x) {
>>>   return o[x];
>>> }
>>> must transform to
>>> function get(o,x) {
>>>   return (x is WeakMap) ? x.get(o) : o[x];
>>> }
>> You're right, I hadn't thought of that.
>>> This is not an acceptable hit for every []-named property access.
>> I intuit (and may be wrong) that even just observing types (weakmap 
>> or stringified type) passed to a []-access can be a good indicator of 
>> how best []-named property access should be JIT-compiled. You pay the 
>> price of the (x is WeakMap) test only the time the JIT warms up.
>> Given what's in current engines, it sounds doable.
> No, it's a hit, pure and simple. Engines do various things, 
> SpiderMonkey does semi-static analysis (type inference), but in 
> generic code, you propose to add a ?: to every [] operation.
I don't understand your point. From the JIT presentations I have watched 
(one per browser vendor except Opera I think) I have understand that JIT 
compilation allows to compile the right efficient things for the + 
operator based on proven (type inference) or observed types. For 
instance, if type information says that the 2 operands of a given + 
operation are strings, then what's compiled is a string concatenation 
without checking types. Likewise if for a given binary +, the 2 operands 
are ints, it's going to be compiled to an addition without the type 
checks/conversions (maybe a guard based on whether types are proven or 

I think the situation is equivalent to if JS had a binary + only for 
numbers, I was suggesting to use it for string concatenation and you 
were answering "no, all binary + operations will take a hit". Early 
engines probably suffered from that, but the JIT thing I've just 
described has proven that real-life JS code (how does it compare with 
your "generic code"?) can be optimized up-to-native assuming some JIT 
warmup cost.

I feel we're in the exact same situation.
Only code taking the deoptimization paths would take a hit. That would 
be code where the same expression "o[p]" can be used with both strings 
and weakmaps. I don't imagine this becoming the norm.

Am I misunderstanding how JIT compilation using type information works?

> I think that's a non-starter. I invite others (Andreas R. especially) 
> to weigh in.
I'm very interested in implementors opinions indeed.


More information about the es-discuss mailing list