On Mon, 15 Dec 2025 12:48:18 GMT, SilenceZheng66 <[email protected]> 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
