G1 concurrent refinement regression

[Thomas Schatzl]

Hi,

On 29.09.25 08:09, Thomas Schatzl wrote:
> 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 :)

That said, increasing this percentage would/should serve as a temporary 
workaround.

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

Thanks,
   Thomas