Do we really need the [[HasOwnProperty]] internal method andhasOwn trap

Claus Reinke claus.reinke at talk21.com
Mon Dec 10 13:40:43 PST 2012


>> Also "compile-time garbage collection" or "compile-time memory
>> management". Then there is the whole area of "linear types" or
>> "uniqueness types", 
> 
> "affine types"
> 
>> which allow for in-place updating (reusing
>> memory) without observable side-effects when absence of other 
>> references can be proven statically. Perhaps also "fusion", which
>> avoids the allocation of intermediate structures, when it can be
>> proven statically that construction will be followed immediately
>> by deconstruction.
> 
> This is all great fun, but really off-target for JS. JS has no type 
> system, lots of aliasing, and a never-ending need for speed.

Seems I haven't replied yet. You do not necessarily need a language
level type system to profit from compile-time memory management.

I don't have any references but -at the time when soft typing had
made the rounds but static typing seemed to rule the functional
programming world in terms of speed- there were some approaches 
for working on internal byte code generated from dynamically typed 
source, to approximate some of the performance gains of source 
level static analysis. 

One way of looking at it was to make information providers and 
consumers explicit as instructions in the byte code, then to try to 
move related instructions closer to each other by byte code 
transformations.

If you managed to bring together a statement that made an
abstract register a string and a test that checked for string-ness, 
then you could drop the test. If you managed to bring together
statements for boxing and unboxing, you could drop the
pair, saving memory traffic. If you managed to limit the scope 
of a set of reference count manipulations, you could replace 
them by bulk updates. No matter how many references there
are to an unknown object coming in, after you make a copy, 
and until you pass out a reference to that copy, you know
you have the only copy and might be able to update in place.

Most of these weren't quite as effective as doing proper
static analysis in a language designed for it, but such tricks
allowed implementations of dynamically typed functional
languages to come close to the performance of statically
typed language implementations.

Claus
 


More information about the es-discuss mailing list