Unexpected marking cycles and full gcs in SPECjbb2015

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.