JDK-8288484 : Unexpected marking cycles and full gcs in SPECjbb2015
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 19
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2022-06-15
  • Updated: 2022-12-14
  • Resolved: 2022-12-14
Related Reports
Relates :  
JDK-8297639 - Remove preventive GCs in G1
Relates :  
JDK-8257774 - G1: Trigger collect when free region count drops below threshold to prevent evacuation failures
Description
While running our internal specjbb2015 benchmark we found unexpected preventive gcs, marking cycles and (short) full gcs with JDK 19, particularly with very large regions (512M in that case) compared to smaller (32M) region sizes.

The problem seems to be g1 full gc allocation unit being a region: with 512M regions, and a lot of threads, any full gc will result in a large minimum amount of regions in old gen. This may be significant enough with a highly tuned application, that this to g1 feels like old gen is very full causing (unwanted) mixed cycles, evacuation failures and potentially more full gcs.

Maybe something could be done in such situations (large regions, many threads, little live data) to compact the heap better so this situation can not occur.
Comments
Closing because the feature will be removed.
14-12-2022
Since by default G1 does not ergonomically enable regions larger than 32M, and ergonomics tries to have 2k regions which is much larger than typical thread counts (at least at the moment), this issue is unlikely to occur in practice. So in a way this is some kind of configuration problem.
23-06-2022
The problem is that the used configuration (very small old gen on a machine with many threads) causes unexpectedly high old gen usage due to g1 full gc: g1 full gc uses full regions as allocation buffers, i.e. the minimum amount of memory allocated for a thread is one region. With very large regions (e.g. 512M), many threads and a comparatively small old gen, G1 will after full gc notice that old gen is full (on a region level), and so causing lots of unexpected mixed gcs to compact the old gen. SPECjbb2015 in particular executes system.gc in a few situations, that cause some unexpected interaction. Preventive GCs actually help in that case as they will trigger shorter gcs (with shorter evacuation failure) and remedy the situation earlier.
23-06-2022