RFR: 8338977: Parallel: Improve heap resizing heuristics [v22]

[SilenceZheng66]

On Tue, 16 Dec 2025 00:15:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk Sure.  I will give detailed description here.
>> 
>> GC：PS MarkSweep、PS Scavenge
>> 
>> JVM configuraton:  
>> -Xmx2g 
>> -Xms256M 
>> -XX:MetaspaceSize=256m 
>> -XX:MaxMetaspaceSize=256m 
>> -XX:+PrintGCDateStamps 
>> -XX:+PrintGCDetails 
>> -XX:-UseAdaptiveSizePolicy 
>> -XX:+PrintAdaptiveSizePolicy 
>> -XX:+HeapDumpBeforeFullGC 
>> -XX:+HeapDumpOnOutOfMemoryError 
>> -XX:HeapDumpPath=export/Logs/ 
>> -Xloggc:/export/Logs/gclogs.log 
>> 
>> JVM version：25.191-b12, although it's an old version without maintenance, I find out the problem might still in the latest version.
>> 
>> Problem Description: 
>> When starting a application(like SpringBoot), objects loading to VM continuously, my CPU usage suddenly began to skyrocket, followed by a full GC lasting over ten minutes with more than 2,700 occurrences. Examining the GC logs revealed that prior to the full GC, several successful young GC events had taken place until the old generation was completely filled. I read the source code and find out when -XX:-UseAdaptiveSizePolicy was set,  VM thread can't expand psOldGen, only GC worker can expand psOldGen's size in that condition. I assume that the transition from the younger generation to the older generation has been successful, so that GC worker's expansion was not reached, that made long term full GC happened.
>> 
>> Check List:
>> 1. Container has enough place for heap expansion
>> 2. Xms and Xmx were setting differently, same configuration in Serial GC can raise heap expansion
>> 
>> GC log sample:
>> // Full GC Starting
>> [PSYoungGen: 76276K->10735K(76288K)] 244793K->181638K(251392K), 0.0078092 secs] [Times: user=0.04 sys=0.00, real=0.01 secs] 
>> 2025-12-10T14:11:58.663+0800: 24.604: [Heap Dump (before full gc): , 0.0000482 secs]2025-12-10T14:11:58.663+0800: 24.604: [Full GC (Ergonomics) [PSYoungGen: 10735K->0K(76288K)] [ParOldGen: 170902K->173351K(175104K)] 181638K->173351K(251392K), [Metaspace: 107770K->107770K(1146880K)], 0.5258832 secs] [Times: user=1.82 sys=0.00, real=0.52 secs] 
>> 2025-12-10T14:11:59.268+0800: 25.210: [Heap Dump (before full gc): , 0.0000684 secs]2025-12-10T14:11:59.269+0800: 25.210: [Full GC (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 173351K->174276K(175104K)] 238887K->174276K(251392K), [Metaspace: 109096K->109096K(1148928K)], 0.3031080 secs] [Times: user=1.10 sys=0.01, real=0.30 secs] 
>> 2025-12-10T14:11:59.710+0800: 25.651: [Heap Dump (before full gc): , 0.0000752 secs]2025-12-10T14:11:59.710+0800: 25.651: [Full GC (Ergonomi...
>
> I’m not very familiar with this output format. The following three flags have been superseded by `-Xlog:gc*`:
> 
> 
> -XX:+PrintGCDateStamps
> -XX:+PrintGCDetails
> -XX:+PrintAdaptiveSizePolicy
> 
> 
> Could you try using `-Xlog:gc*` instead? I think that would make it easier for me to understand the issue.
> 
> Additionally, the change from `8338977: Parallel: Improve heap resizing heuristics` should have significantly improved adaptive resizing behavior. Running with `-XX:-UseAdaptiveSizePolicy` is not a configuration we recommend. Would it be possible for you to rerun your benchmark using a build that includes `8338977`, with `UseAdaptiveSizePolicy` enabled?

@albertnetymk Since my JVM's version is 25.191-b12, it does not support `-Xlog:gc*` configuration. I also know that your work aim to improve performance when `UseAdaptiveSizePolicy` enabled, but in my situation default configuration is disable that. Now I just curious about is it a bug when people use configurations as following and could raise full GC problems and heap can't expand. 

-Xmx2g
-Xms256M
-XX:-UseAdaptiveSizePolicy

I understand that's totally not your business, but if you know who can explain or confirm this "bug", just let me know, thx!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2622073234