On Tue, 16 Dec 2025 00:15:58 GMT, Albert Mingkun Yang <[email protected]> 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
