Garbage collectors determine effective page size for a given Java heap (and other data structures) by calling os::page_size_for_region_aligned() with a min_page argument of 8 which is fixed.
In some cases this may cause the algorithm to use a suboptimal page size, in particular if the page size is very large compared to the reserved space size.
The intent of this divisor is to guarantee a small amount of flexibility in committing only parts of the heap if desired (e.g. -Xms != -Xmx).
E.g. when using 1GB large pages, the forced divisor of 8 will cause GC to use small pages if e.g. heap size min and max has been set to 4GB (no on-demand heap commit requested).
In that example 4GB divides to 512M, and the algorithm selects the next smaller page size which is 4k on x86, which may be somewhat detrimental to performance.
At least the generational collectors (serial, cms, parallel) have that issue, but also check others.
In some cases this may cause the algorithm to use a suboptimal page size, in particular if the page size is very large compared to the reserved space size.
The intent of this divisor is to guarantee a small amount of flexibility in committing only parts of the heap if desired (e.g. -Xms != -Xmx).
E.g. when using 1GB large pages, the forced divisor of 8 will cause GC to use small pages if e.g. heap size min and max has been set to 4GB (no on-demand heap commit requested).
In that example 4GB divides to 512M, and the algorithm selects the next smaller page size which is 4k on x86, which may be somewhat detrimental to performance.
At least the generational collectors (serial, cms, parallel) have that issue, but also check others.
- relates to
-
JDK-8208277 Code cache heap (-XX:ReservedCodeCacheSize) doesn't work with 1GB LargePages
- Resolved