On Tuesday, November 19, 2013 12:35:40 PM UTC-8, Dmitry Lomov wrote: > > On Tue, Nov 19, 2013 at 9:00 PM, Trevor Norris > <[email protected]<javascript:> > > wrote: > >> On Tuesday, November 19, 2013 2:04:45 AM UTC-8, Dmitry Lomov wrote: >>> >>> Here is the change: https://code.google.com/p/v8/source/detail?r=15205 >>> Instead of weak handles, I taught our GC to free array buffer backing >>> store when array buffers die. >>> >> >> That's awesome. Something like that is exactly what I originally wanted >> as an extension of Object::SetIndexedPropertiesToExternalArrayData() where >> a user could pass in a fourth optional bool that told the Object to >> automatically clean up the attached external memory when the Object was >> GC'd. >> > > Note that this is not so easy. V8's GC does not visit garbage; therefore > there is a special machinery in place to visit dying ArrayBuffers (all > ArrayBuffers are in a weak list, which requires a special in-object field > and GC additional GC machinery to maintain them) >
Sorry. Didn't mean to insinuate that it was. Just a pipe-dream that I'll always hang onto. :) Just checking in to see what the proposed status is. Also, have a few results from that 16KB/32KB allocation issue. Sorry, haven''t been able to reproduce with just d8, but maybe you'll find some of this helpful (using latest Node with v8 3.22.24.5). Started with some simple syscall tracing and got the following: 32KB Uint8Array Allocations =========================== $ strace -c ./node -e 'for (var i = 0; i < 1e6; i++) new Uint8Array(1024 * 32);' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 32.09 0.001205 1 1250 brk 16KB Uint8Array Allocations =========================== $ strace -c ./node -e 'for (var i = 0; i < 1e6; i++) new Uint8Array(1024 * 16);' % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 98.68 0.536939 4 147228 brk So we can see that for some reason brk is being called +40x's more for 16KB allocations then 32KB allocations. Interestingly though this doesn't happen for just ArrayBuffer's. Here's the call graph generated by perf for each of the calls: https://gist.github.com/trevnorris/7726634 It does appear that some GC strangeness is going on. You'll see that looking at the _int_free stacks. I haven't had time to inspect the v8::internals to see exactly what's going on, and was hoping you'd have an idea before I dive in. Have a good weekend. -- -- 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.
