From profiling stanford-crypto-sha256-iterative with Instruments, it looks like we're spending > 10% of our time calling CFRunLoopTimerSetNextFireDate inside of Heap::reportExtraMemoryCost. It's a shame this function is so expensive. We have code that tries to avoid calling it too much, but it looks like it's either not working at all or it's not aggressive enough in its mitigation.
<rdar://problem/16394074>
In GCActivityCallback::didAllocate, lastGCLength() returns 0 if we've never collected before. Some of the benchmarks are never running a single EdenCollection, which causes them to repeatedly call scheduleTimer with a newDelay of 0. This defeats our timer slop heuristic, causing us to invoke CFRunLoopTimerSetNextFireDate a couple orders of magnitude more than we normally would. The fix is to seed the last GC lengths in Heap with a non-zero length so that our heuristic works.
Created attachment 227491 [details] Patch
Comment on attachment 227491 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=227491&action=review r=me > Source/JavaScriptCore/heap/Heap.cpp:284 > + // schedule the timer if we've never done a collction. *collection*
Committed r166099: <http://trac.webkit.org/changeset/166099>