G1 GC Eden区大小调整算法咨询及异常问题排查求助

This sounds like a tricky G1GC tuning issue—let’s break down the possible reasons why your Eden space is unexpectedly shrinking to 528M instead of staying in the 4-6.5G range you’d expect based on the algorithm you referenced.

Possible Root Causes to Investigate #

1. Unnoticed STW Pause Spikes Triggering Aggressive Downsizing #

The algorithm you found ties Eden size adjustments to recent STW times, but it’s easy to miss mixed GC pauses or short bursts of longer pauses that push G1 into downsizing mode. Even a single pause exceeding your MaxGCPauseMillis setting can trigger a rapid reduction in Eden size, and G1 might take several cycles to ramp back up.

• Action: Dig deeper into your GC logs to check all STW pause times (not just Young GC) around the time Eden shrank. Look for any pause that exceeds your configured MaxGCPauseMillis—even a one-off spike could be the trigger.

2. Dynamic Parameter Overrides or Misconfiguration #

It’s possible that critical G1GC parameters are being modified at runtime, or your initial configuration has conflicting settings that override the expected Eden sizing logic:

• Check if tools like JConsole, VisualVM, or custom application code (using HotSpotDiagnosticMXBean) are dynamically altering parameters like G1NewSizePercent, G1MaxNewSizePercent, or G1ReservePercent.
• Verify you haven’t set conflicting flags like -Xmn (fixed young gen size)—while G1 usually ignores this, some older JDK versions might handle it unexpectedly, locking Eden to a smaller size.
• Double-check if your MaxGCPauseMillis is set too aggressively. If the target is unrealistically low, G1 will keep shrinking Eden to try and hit the pause time, even if it’s counterproductive.

3. Old Generation Pressure Forcing Eden Compression #

G1 prioritizes maintaining free space in the old generation to avoid concurrent mode failures. If your old gen usage spiked suddenly (e.g., from large objects being allocated directly to old gen, or a surge in long-lived objects), G1 will shrink Eden to reserve more space for the tenured region.

• Action: Monitor old generation usage trends around the time Eden shrank. Look for sudden increases in tenured space utilization—this would explain why G1 is limiting Eden to a smaller size.

4. Concurrent Mode Failures (CMF) or Full GCs #

If G1 encounters a Concurrent Mode Failure (when the concurrent marking can’t finish before old gen fills up), it triggers a Full GC. After a Full GC, G1 often resets the young gen size to the minimum defined by G1NewSizePercent, which could be your 528M value.

• Action: Scan your GC logs for Concurrent Mode Failure or Full GC entries. These events are major disruptions that can reset G1’s sizing strategy entirely.

5. JVM Version-Specific Bugs #

Certain older JDK versions (especially early builds of JDK 8u or JDK 11) have known bugs related to G1’s Eden sizing logic. For example, some versions fail to properly ramp up Eden size after a temporary shrink, or miscalculate the available space for young gen.

• Action: Check your JVM version (java -version) and look for known bugs in OpenJDK’s bug database related to G1 Eden size adjustment. Upgrading to a newer patch release might resolve the issue.

Verification Steps to Narrow It Down #

• Use jinfo -flags <your-app-pid> to dump the current active G1GC parameters. Confirm that G1NewSizePercent, G1MaxNewSizePercent, G1ReservePercent, and MaxGCPauseMillis match your expected configuration.
• Correlate Eden size changes with GC pause times, old gen usage, and any Full GC/CMF events in your logs using tools like GCViewer or GCEasy.
• If possible, test with a newer JVM version to rule out version-specific bugs.

内容的提问来源于stack exchange，提问作者zbliu