UNCONFIRMED 68440
Peak execution time of the JavaScriptCore garbage collector causes pauses that prevent applications running at a constant frame rate.
https://bugs.webkit.org/show_bug.cgi?id=68440
Summary Peak execution time of the JavaScriptCore garbage collector causes pauses tha...
michaelbraithwaite
Reported 2011-09-20 08:06:10 PDT
With JSC from http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.4.2 on Windows and Mac. For applications, e.g. games, that require smooth animation a constant frame rate is desired, typically 60hz. Running complex JavaScript applications under JavaScriptCore we see various pauses that are caused by Heap::reset(). Putting in some basic timing code shows peak execution time on a Core i5 @3.45Ghz regularly exceed 0.1 seconds and can be up to 0.25s for some titles that have very many objects (Heap.objectCount() ~= 3million). Breaking this down we see Heap::markRoots() take ~60% of this and MarkedSpace::sweep() the other 40% (when it executes). We can work on reducing the number of objects created but the cost is more than 10x 1/60s on a moderately fast CPU and on slower machines, e.g. some laptops, the pauses are obviously much larger. I can see in the trunk changes to the heap, e.g. adding some WeakReference code (for generational gc?). Are there other major changes planned to speed things up or reduce the peak cost (split up sweep cost or/and use other threads)?
Attachments
Test showing peak gc cost. (3.71 KB, text/html)
2011-09-22 09:05 PDT, michaelbraithwaite
no flags
Geoffrey Garen
Comment 1 2011-09-20 18:11:23 PDT
Can you supply a URL or test case to reproduce this with?
michaelbraithwaite
Comment 2 2011-09-22 09:05:27 PDT
Created attachment 108342 [details] Test showing peak gc cost.
michaelbraithwaite
Comment 3 2011-09-22 09:06:20 PDT
(In reply to comment #2) > Created an attachment (id=108342) [details] > Test showing peak gc cost. I put together a test that shows the peak hitting ~100ms for me and these do match the garbage collector cost, i.e. Heap::reset(). The allocation patterns in the various games vary so this isn’t meant to match that but illustrates the point with the volume of objects. The Heap::reset() looks fairly linear in cost with the number of objects so the issue is more about changing that behaviour. It looks like both V8 and Mozilla are going down the incremental gc root. Is that on the roadmap?
michaelbraithwaite
Comment 4 2011-12-05 05:32:21 PST
This is the test the v8 people put together for their incremental GC:- http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks/spinning-balls/index.html
Note You need to log in before you can comment on or make changes to this bug.