| Summary: | The concurrent GC should have a timeslicing controller | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> | ||||
| Component: | JavaScriptCore | Assignee: | 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
Filip Pizlo
2016-11-15 12:27:09 PST
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 |