Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

David Bruant bruant.d at
Mon Nov 19 04:04:19 PST 2012

Le 19/11/2012 12:37, Brendan Eich a écrit :
> David Bruant wrote:
>> So my position is let's not bake performance bottlenecks in the 
>> language (which we tend to do naturally anyway) and for things that 
>> can be optimized, let's say that the implementations will pay the 
>> cost of the static/runtime analysis if it's really felt by them like 
>> a worthwhile idea. 
> No, sorry. Allocations will always cost. It's unphysical to argue 
> otherwise. I've been burned too many times by this, even if it's a 
> small constant overhead. Those add up, as David Bacon used to point 
> out to good effect.
I've made a point where I suggested that with type inference (which cost 
has been already paid), the extra allocation could be avoided. My point 
is that it would be up to implementors to decide whether using this type 
information is worthwhile against the extra allocation. This extra 
allocation burns only if it occurs.

I wish to point out a little thought on the topic of memory management. 
As far as I know, all GC algorithms I'm aware of are runtime algorithms, 
meaning that the primitives of these algorithms are objects and 
references between objects. I have never heard of memory management 
system that would take advantage of source code informations to not 
allocate memory if it's proven to be unused after allocation (or 
allocate less if it's proven only part will be used).
Is it a stupid idea? Too much effort? The conjonctions of 2 research 
areas where people usually don't talk to one another?


More information about the es-discuss mailing list