"Super" hoisting

Nicolas B. Pierron nicolas.b.pierron at mozilla.com
Fri May 13 16:37:14 UTC 2016

On Fri, May 13, 2016 at 4:19 PM, Herby Vojčík <herby at mailbox.sk> wrote:
> Nicolas B. Pierron wrote:
>> I do not understand how having local variable should change any GC
>> pattern unless you are creating them in the for-loop body.
> If I understand correctly, the problem is in not reusing the objects. If you
> do `var x = new X()` in every call of the method, GC should take care of
> every `new X()`. OTOH, they are young object, and young space should be this
> sort-of pool like quick thing.

Yes, the nursery should handle such cases by removing the young & dead objects.

> That's why I suggested that what is in way wanted here, is in fact pooling
> of X instances (and maybe not necessarily by instance of their client).
> Which can be inlined as well, as it is pretty easy:
>   var x = poolOfXs.pop() || new X();
> to get an x, and
>   poolOfXs.push(x);
> to put it back. This may actually save even more GC (as only as much
> instances are created as needed).

One problem I see with manually implementing a pool of objects, is
that the JS engine has no clue that your are making an allocator on
your own.

Scalar Replacement should be able to remove "most" of these
allocations, as long as there is a single allocation site per variable
(at the moment in SM).  On the other hand, this can only work with GC
allocations which are not escaped.

The problem with a pool allocator, is that the optimizer has no "easy"
way to know that you are effectively making an allocator.  Thus,
optimization such as scalar replacement have no way to know that they
can skip the allocation, nor the computation of the properties.

Nicolas B. Pierron

More information about the es-discuss mailing list