Is `undefined` garabage collectable?
rossberg at google.com
Tue May 10 10:33:12 UTC 2016
Arrays are probably your best bet (but don't ever `delete` elements, or
change the size of your array!).
I don't understand what you mean by "placeholder". But FWIW, array keys
(i.e., small integers) are usually unboxed, i.e., not heap-allocated.
A general advise, though: don't be over-concerned with GC. There are a lot
of misconceptions about its performance. It is quite efficient in most
practical cases -- much more so than most attempts to work around it and
manage life-times manually.
On 9 May 2016 at 20:06, /#!/JoePea <joe at trusktr.io> wrote:
> 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
> 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>
>> 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
>> 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
>> potentially cause allocation and thus GC. Certainly nothing involving
>> dynamic data structures.
>> On 5 May 2016 at 07:48, /#!/JoePea <joe at trusktr.io> wrote:
>>> > The only v8 shell I have lying around is too old (18.104.22.168) to have
>>> Set, so I can't tell you what it would do.
>>> On my first attempt, I noticed 8 Major GCs:
>>> On second attempt, no Major GCs:
>>> 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 (22.214.171.124) 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.
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss