6% SunSpider commandline regression due to r165940

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Mark Hahnenberg]

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.

[Mark Hahnenberg]

<rdar://problem/16394074>

[Mark Hahnenberg]

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]

Created attachment 227491 [details]
Patch

[Michael Saboff]

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]

Committed r166099: <http://trac.webkit.org/changeset/166099>