In the review for JDK-8244505 we noticed that the calculation of the long term pause time ratio in G1Policy::compute_pause_time_ratios() is wrong:
"
double long_interval_ms = (end_time_sec - oldest_known_gc_end_time_sec()) * 1000.0;
_long_term_pause_time_ratio = _recent_gc_times_ms->sum() / long_interval_ms;
Let's assume that we have the following pauses on the timeline in G1Analytics, where "X" means pause (the number at the end of an "X" block is just a running number), "-" means mutator time.
XXX1-----XX2---XXX3---------XXXX4---XXXXXX5--------XX6
^--------------long_interval_ms-------------------^
(optimized for fixed font viewing)
Currently oldest_known_gc_end_time_sec() is at the end of pause 1, and _recent_gc_times_ms contains all gc pause times from 1 to 5. We did not call update_recent_gc_times() yet.
Now the (existing) calculation calculates "long_interval_ms" from the end of pause 1 to the end of pause 6 (current), and divides by the sum of pauses 1 to 5 - which is wrong as pause 1 can be different to pause 6 in length. However, there is the the code permeating assumption (not documented, sorry :)) that pauses are fairly regular. So this is somewhat accurate."
Fix this.
(Review thread starts at https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/031056.html)
"
double long_interval_ms = (end_time_sec - oldest_known_gc_end_time_sec()) * 1000.0;
_long_term_pause_time_ratio = _recent_gc_times_ms->sum() / long_interval_ms;
Let's assume that we have the following pauses on the timeline in G1Analytics, where "X" means pause (the number at the end of an "X" block is just a running number), "-" means mutator time.
XXX1-----XX2---XXX3---------XXXX4---XXXXXX5--------XX6
^--------------long_interval_ms-------------------^
(optimized for fixed font viewing)
Currently oldest_known_gc_end_time_sec() is at the end of pause 1, and _recent_gc_times_ms contains all gc pause times from 1 to 5. We did not call update_recent_gc_times() yet.
Now the (existing) calculation calculates "long_interval_ms" from the end of pause 1 to the end of pause 6 (current), and divides by the sum of pauses 1 to 5 - which is wrong as pause 1 can be different to pause 6 in length. However, there is the the code permeating assumption (not documented, sorry :)) that pauses are fairly regular. So this is somewhat accurate."
Fix this.
(Review thread starts at https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/031056.html)