Is `undefined` garabage collectable?

/#!/JoePea joe at trusktr.io
Mon May 9 18:06:51 UTC 2016


Thanks Andreas, that's helpful to know. In general, is there some way to
keep a list (adding removing things over time) while avoiding GC?

For example, I thought I could place and remove items into a list (f.e. Set
or Map, while having my own references to all the items and the list and
outside of the list as well as to the list itself), but as you pointed out
that still can have need for GC.

I know you said

> In general, there is very little you can do in JavaScript that does not
potentially cause allocation and thus GC

But, I would at least want to know that I minimized GC as much as possible.
My first hunch (for my case) would be to make a linked list out of the
items I need to have a "list" of, where each item's link (reference) to the
next item is also one of the references that I already hold outside of the
list?

It seems that with Arrays (and Sets and Maps) that deleting an item from
the list also deletes the placeholder that was used for that item (in the
case of Array, the placeholders would be the numerical keys that are
deleted when an item is popped for example), and I'm guessing (with my
still expanding VM knowledge) that those placeholders are GCed separately
from the thing that was referenced to by the placeholder (so even if the
placeholder contained `null` there would still be GC). Is that a good guess?

I'll be experimenting...

On Mon, May 9, 2016 at 2:28 AM, Andreas Rossberg <rossberg at google.com>
wrote:

> The `undefined` value is represented in exactly the same way as `true`,
> `false`, and `null` in V8. They're so called "oddballs" internally, global
> values that are neither allocated nor freed.
>
> Either way, the key/values of a (regular) map do not keep anything alive
> about the map. Adding or removing entries from a set or map can of course
> cause allocation/deallocation, regardless of the keys/values themselves.
> (Similarly if you are using regular objects as maps, btw.)
>
> There are also lots of other things that cause allocation/deallocation
> under the hood of a JavaScript engine, e.g. compilation, optimisation,
> deoptimisation, etc. Some of that predominantly happens at start-up. If you
> want to reduce random noise from your experiments, try to warm up the code
> first. But even then, don't read too much into micro-benchmarks -- JS VMs
> are far too complicated, dynamic, and heuristics-based to draw useful
> conclusions from tiny tests (that's e.g. why JSPerf tests are often
> bollocks).
>
> In general, there is very little you can do in JavaScript that does not
> potentially cause allocation and thus GC. Certainly nothing involving
> dynamic data structures.
>
> /Andreas
>
>
> On 5 May 2016 at 07:48, /#!/JoePea <joe at trusktr.io> wrote:
>
>> > The only v8 shell I have lying around is too old (3.14.5.10) to have
>> Set, so I can't tell you what it would do.
>>
>> On my first attempt, I noticed 8 Major GCs:
>> https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png
>>
>> On second attempt, no Major GCs:
>> https://cloud.githubusercontent.com/assets/297678/15036788/c066483a-1248-11e6-970b-3f9d20710bbc.png
>>
>> I wonder why. I'm in Chrome 50.
>>
>> So, the second attempt looks good. I'm not sure why the first is so
>> different. I tried it a few times, but I only got that Major GC zig-zag the
>> first time.
>>
>> Thanks for pointing out Set!
>>
>> On Wed, May 4, 2016 at 7:30 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>>> On 5/4/16 5:03 PM, Steve Fink wrote:
>>>
>>>> The only v8 shell I have lying around is too old (3.14.5.10) to have
>>>> Set, so I can't tell you what it would do.
>>>>
>>>
>>> I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and
>>> it does 1163 minor ("Scavenge") GCs on your testcase.  It also does 1163
>>> minor GCs if I take out the add() calls.  It does none if I remove the
>>> clear() calls, no matter whether the add() calls are there or not.
>>>
>>> -Boris
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/80ecd1bd/attachment.html>


More information about the es-discuss mailing list