RESOLVED FIXED 130617
6% SunSpider commandline regression due to r165940 
https://bugs.webkit.org/show_bug.cgi?id=130617
Summary 6% SunSpider commandline regression due to r165940
Mark Hahnenberg
Reported 2014-03-21 14:22:57 PDT
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.
Attachments
Patch (1.90 KB, patch)
2014-03-21 14:32 PDT, Mark Hahnenberg 		msaboff: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mark Hahnenberg
Comment 1 2014-03-21 14:23:12 PDT
<rdar://problem/16394074>
Mark Hahnenberg
Comment 2 2014-03-21 14:26:05 PDT
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.
Mark Hahnenberg
Comment 3 2014-03-21 14:32:09 PDT
Created attachment 227491 [details] Patch
Michael Saboff
Comment 4 2014-03-21 14:47:37 PDT
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*
Mark Hahnenberg
Comment 5 2014-03-21 14:53:57 PDT
Committed r166099: <http://trac.webkit.org/changeset/166099>
Note You need to log in before you can comment on or make changes to this bug.