Hi Andrei, V8 has an optimization that turns arrays into unboxed double arrays. If you build a debug build of V8 you could do %DebugPrint(arr1) for example, and you'll see that the elements kind is set to FAST_DOUBLE_ELEMENTS (or FAST_HOLEY_DOUBLE_ELEMENTS).
This means that doubles are stored unboxed in the array, i.e., there's no heap-number wrapping around them. When you read such a number in optimized code, it goes straight to a double-register. When you write it back to a double array, it gets written directly inline into the array. This is a lot faster than having to allocate heap-numbers and wrap/unwrap them for computation. There's a catch however: fullcodegen, our slow compiler used to gather typefeedback, does not support reading raw doubles. It can only work with heap numbers. This means that when you read a double from a raw-double array in fullcodegen, for example to copy it, you have to allocate a heap-number and wrap the double in it. When you write this heap-number to another double-array, the value gets taken out and written into the next array. Thus the temporary heap-number is now garbage. So if you'd do trace-opt, hopefully you wouldn't see GC anymore after the point where your copying function is optimized. hth, Toon On Sat, Apr 20, 2013 at 4:42 AM, Andrei Kashcha <[email protected]> wrote: > I've been puzzling over V8 GC behavior for the past few days. I made a > really simple program which copies content of one array into another ( > https://gist.github.com/anvaka/5423226 ), and I'm seeing lots of garbage > collection in the d8 console with --trace_gc flag. But, with very simple > tweaks garbage is not produced: > > This does not happen when arrays contain integer numbers > This does not happen when any of the array's elements is printed to the > console before or after the copy cycles > This does not happen when the copy is executed within a function scope. > > Looking at the GC histograms "garbage" is comprised of nothing > but HEAP_NUMBER_TYPE. When debugging the v8 source code I indeed see tones > of calls to Runtime_AllocateHeapNumber in the runtime.cc file, but > unfortunately my assembly programming skills do not allow me to fully > understand what's going on here. > > Can someone shed some light on this behavior? > > -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
