Bug 164783 – The concurrent GC should have a timeslicing controller

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Filip Pizlo]

Patch forthcoming.

[Filip Pizlo]

Created attachment 294864 [details]
the patch

[WebKit Commit Bot]

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 on attachment 294864 [details]
the patch

r=me

[Geoffrey Garen]

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]

(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]

Landed in https://trac.webkit.org/changeset/208750