Bug 164783

Summary: The concurrent GC should have a timeslicing controller
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: JavaScriptCoreAssignee: Filip Pizlo <fpizlo>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cdumez, cmarcelo, commit-queue, dbates, keith_miller, mark.lam, msaboff, saam
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 149432    
Attachments:
Description Flags
the patch ggaren: review+

Filip Pizlo
Reported 2016-11-15 12:27:09 PST
Patch forthcoming.
Attachments
the patch (13.40 KB, patch)
2016-11-15 12:34 PST, Filip Pizlo
ggaren: review+
Filip Pizlo
Comment 1 2016-11-15 12:34:23 PST
Created attachment 294864 [details] the patch
WebKit Commit Bot
Comment 2 2016-11-15 12:35:32 PST
Attachment 294864 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/heap/Heap.cpp:129: Declaration has space between type name and * in ramSize * Options [whitespace/declaration] [3] Total errors found: 1 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.
Geoffrey Garen
Comment 3 2016-11-15 13:02:51 PST
Comment on attachment 294864 [details] the patch r=me
Geoffrey Garen
Comment 4 2016-11-15 13:03:50 PST
Comment on attachment 294864 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=294864&action=review > Source/JavaScriptCore/ChangeLog:26 > + 1ms: 30% worse than 2ms on splay-latency. I think this result deserves some investigation: Why does trying to run for less than 1ms cause pauses > 1ms? Also, I think most programmers would intuitively feel more comfortable with pauses on the order of 1ms vs 2ms.
Filip Pizlo
Comment 5 2016-11-15 13:12:07 PST
(In reply to comment #4) > Comment on attachment 294864 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=294864&action=review > > > Source/JavaScriptCore/ChangeLog:26 > > + 1ms: 30% worse than 2ms on splay-latency. > > I think this result deserves some investigation: Why does trying to run for > less than 1ms cause pauses > 1ms? Also, I think most programmers would > intuitively feel more comfortable with pauses on the order of 1ms vs 2ms. 1ms isn't the pause time. It's the period. The pause time is 1ms * targetCollectorUtilization. So the answer is probably: OS timing granularity. Even if the OS has the ability to scheduling timers on sub-1ms granularity, most other timers aren't scheduled that way, so the sub-1ms timeouts probably just get rounded. As you go for smaller timeouts, I bet that your wakeup times get more noisy, which then means that when the collector asks for "timeout in 0.34ms", it really gets "timeout in 0-1ms at random". So splay performs worse because the collector isn't really hitting its utilization target. On the other hand, with 2ms, I bet that the rounding works out less badly. The reason why I did the experiment over 1, 2, 3, and 4ms is because I figured that it was going to be a war between timing granularity on one end and pauses getting too long on the other. 2ms seems to be the local optimum.
Filip Pizlo
Comment 6 2016-11-15 13:15:23 PST
Note You need to log in before you can comment on or make changes to this bug.