G1 concurrent refinement regression

Thomas Schatzl thomas.schatzl at oracle.com
Mon Sep 29 06:09:00 UTC 2025


Hi Brian,

On 28.09.25 18:19, Brian S O'Neill wrote:
> I'm observing an interesting regression between build 26-ea+16-1649 and 
> build 26-ea+17-1764 with respect to concurrent refinement. I suspect the 
> cause is JEP 522.
> 
> I ran a stress test in which GC pauses are about 25ms in the steady 
> state. With 26-ea+16-1649, concurrent refinement is never initiated.

Thanks for trying out latest EAs.


 > With 26-ea+17-1764 (JEP 522) concurrent refinement starts after the
 > test has run for a few minutes. Eventually, concurrent refinement runs
 > back to back forever, wasting a CPU core and affecting overall
 > performance.
 >
 > [...]
 >
 > The problem goes away when I set -XX:MaxGCPauseMillis=500 or higher.
 > Considering that the pauses are always well below the 200ms default,
 > I'm surprised that concurrent refinement occurs at all.


Before and after this change, refinement is and has been driven by time 
allocated for refinement in the pause.

By default this is 10% of the maximum pause time goal 
(-XX:G1RSetUpdatingPauseTimePercent). This is, at a pause time goal of 
200ms, 20ms. It is somewhat unlikely that this part of the GC takes 20ms 
out of your 25ms pauses, so I suspect some bug :)

Is it possible to add gc+refine=debug,gc+phases=debug to your logs and 
send them here to better analyze what is happening?

Thanks,
   Thomas



More information about the hotspot-gc-dev mailing list