Stephanie measured a ~25% regression on v8-splay, caused by http://trac.webkit.org/changeset/80052.
This regression is measurable in the SunSpider harness but not the v8 harness.
The extra time is in a kernel call: 0.1% 18.3% mach_kernel thread_setuserstack
thread_setuserstack seems to be a mis-symbolication by Shark. Really, this is the vm_map kernel trap. The extra calls to vm_map occur because the block size is now 8KB instead of 256KB, so we're making more kernel calls to map in a large heap.
I meant to say the block size is now 16KB.
Since this regression only shows up in the SunSpider harness, I don't think it's worth fixing. Running the v8 tests through the SunSpider harness is a Frankensteinian configuration. In this case, what you see is the cost of constructing an 8000 node data structure and then performing only 80 modifications of it. Here, initial heap growth dominates everything else in the benchmark. In the real v8 benchmark, the orders of magnitude are reversed, and there are orders of magnitude more modification operations than initial setup operations.
Reopening because the regression also occurred testing in browser
<rdar://problem/9099476>
Created attachment 87406 [details] Patch
Comment on attachment 87406 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=87406&action=review > Source/JavaScriptCore/runtime/Heap.cpp:386 > - size_t proportionalBytes = static_cast<size_t>(1.5 * m_markedSpace.size()); > + size_t proportionalBytes = 2 * m_markedSpace.size(); It’s unclear where the constant 2 comes from. Your comments in change log talk about 1X vs. .5X so there is obviously something going on here that I just can’t spot. A comment explaining what we are accomplishing by multiplying by 2 and why 2 is the right value could be quite helpful.
Committed r82327: <http://trac.webkit.org/changeset/82327>