RFR: Avoid divide by zero error, improve variable names
Y. Srinivas Ramakrishna
ysr at openjdk.org
Thu Dec 22 00:02:21 UTC 2022
On Wed, 21 Dec 2022 23:49:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> Depending on when the periodic thread runs the accounting task and how much CPU time the process receives, we may see a very small elapsed process time. Such a time should not be used to compute MMU.
>
> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 97:
>
>> 95: double process_time_s = process_time_seconds();
>> 96: double elapsed_process_time_s = process_time_s - _process_reference_time_s;
>> 97: if (elapsed_process_time_s <= 0.01) {
>
> Is there a different mechanism one could use to check if there was an update? E.g. a change in the count of GC cycles started or ended, rather than relying on the magnitude of the difference, although the magnitude of the difference may still be sufficient. One related question: is this unit "seconds" or some smaller unit? The `_s` implies it's a second and 0.01 s is 10 ms which is not insubstantial...
In general the synchronous, time-based, sampling of the MMU suffers from this issue of high variance by catching the co-initial or co-terminal portion of a cycle. Have you looked at the variance of MMUs to see if you should sample only at the end of complete cycles _synchronous with cycles_ rather than using a _time-based sampling trigger_? Anyway something to think about a little bit. Each has its advantages and disadvantages, but how we gather these stats would matter if used as the basis for the error signal that drives your sizing control loop.
-------------
PR: https://git.openjdk.org/shenandoah/pull/188
More information about the shenandoah-dev
mailing list