Patch forthcoming.
Created attachment 294864 [details] the patch
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.
Comment on attachment 294864 [details] the patch r=me
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.
(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.
Landed in https://trac.webkit.org/changeset/208750