Direct proxies update

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 29 14:07:43 PST 2011


On Nov 30, 2011, at 8:15 AM, David Bruant wrote:

>> 
> Avoiding an extra allocation is the only worry for this last point. Very much like Tom worried about mirror allocation at https://mail.mozilla.org/pipermail/es-discuss/2011-November/018734.html
> 
> Digression about memory in JS implementations:
> I've been following the MemShrink effort in Firefox. Data structures have been shrinked, fragmentation has been reduced making a better use of memory, but I have seen much less work toward reducing the number of allocations. This is certainly because the study of when an allocation is required or not is usually complicated.

A sign that your garbage collector isn't good enough:  People are writing style guides that  tell developers that they should avoid allocating objects.

Objects serve as one of our primary abstraction mechanisms (the other is functions and function closures have similar allocation issues). Anytime you you tell programmers not to allocate you take away their ability use abstraction to deal with complexity.

A good GC should (and can) make allocation and reclamation of highly ephemeral objects so cheap that developers simply shouldn't worry about it.  This is not to say that there are no situations where excessive allocations may cause performance issues but such situations should be outliers that only need to be dealt with when they are actually identified as being a bottleneck.  To over simplify: a good bump allocation makes object creation nearly as efficient as assigning to local variables and a good multi-generation ephemeral collector has a GC cost that is proportional to the number of retained objects not the number of allocated objects.  Objects that are created and discarded within the span of a single ephemeral collection cycle should have a very low cost.  This has all been demonstrated in high perf memory managers for Smalltalk and Lisp. 

> I don't know what the exact status of implementations is, but what happens in current JS engines when the expression '[].forEach.call' is met? Is the allocation of an array actually performed? Hopefully not, I would not be surprised if it was.

I suspect they don't optimize this although arguably they should. However, if you buy my argument then it really doesn't make much difference.  Implementations should put the effort into building better GCs.

> ...
> Looking through Promise methods (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#promise_methods), I realize that these (besides p.when and p.end) could just be replaced by the Reflection API being adapted to work with promises.

Stated slightly differently, a promise can be thought of as a specific kind of object mirror.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111130/1b0ac9c2/attachment.html>


More information about the es-discuss mailing list