Direct proxies update

David Bruant bruant.d at
Tue Nov 29 15:24:31 PST 2011

Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
> 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
>> 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.
I agree with you with some restictions.
- For a native API, the cost of function closure is null (since the
function does not need a scope to capture variable)
- Objects are an interesting abstraction as long as they have a state.
For the specific example of Reflection API, the stateless API that Tom
started seems to prove that a reflection API does not need a state. In
that case, why bothering allocating objects?
That's the same reason why math functions are properties of the Math
object and not "math objects".
However, having an object-oriented DOM makes a lot of sense to me since
objects have a state (children, node type, etc.). I'm not sure we could
easily and conviniently turn the DOM into a set of stateless functions.

> A good GC should (and can) make allocation and reclamation of highly
> ephemeral objects so cheap that developers simply shouldn't worry
> about it.
I agree on the reclamation part, but I don't understand what a GC can do
about allocation of ephemeral (or not) objects.

> 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.
If a garbage collection is triggered when a generation is full, then,
your GC cost remains proportional to your number of allocation.

If a garbage collection is triggered at constant intervals, then it
probably runs for nothing (or too few) too often.

>> I don't know what the exact status of implementations is, but what
>> happens in current JS engines when the expression '[]'
>> 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.
For this particular case where the object is not ephemeral, but
completely useless, a GC will still cost you something (even if very
small), while static analysis can tell you to not allocate at all. I'm
not talking about a smaller cost of allocation+discard, but nullifying
it with a constant (and small) time of static analysis.
var a = [1];
function f(e, i){a[i] = Math.random();}

    [], f);
Without static analysis, the first array is allocated and this will run
the GC. With static analysis, the GC has no reason to run: the first
array does not need to be allocated since its reference is never used
anywhere after the retrieval of forEach (which is looked up directly on
Array.prototype if the implementation is conformant to ES5.1).

I'll take actual garbage as a metaphor, I am pro recycling (garbage
collection), but to recycling, I prefer to avoid buying things with
excessive packaging. This way I produce less garbage (less allocation).
Maybe should we apply basics of ecology to memory management? ;-)

I agree with you that abstractions are a good thing and I won't
compromise them if they are necessary. But it should not be an excuse to
allocate for no reason, even if it's cheap. And while garbage collection
should be improved, if we can find cheap ways to allocate less (at the
engine or programmer level), we should apply them.

>> ...
>> Looking through 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.
Interesting :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list