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

[Albert Mingkun Yang]

On Mon, 15 Dec 2025 12:48:18 GMT, SilenceZheng66 <duke at openjdk.org> wrote:

>> @SilenceZheng66 Could you elaborate the issue, ideally, in a JBS ticket? (A reproducer/gc-log would be nice, but detailed description works as well.)
>
> @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 (Ergonomics) [PSYoungGen: 65536K->0K(76288K)] [ParOldGen: 174276K->174980K(...

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?

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

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