-
Type:
Enhancement
-
Resolution: Unresolved
-
Priority:
P4
-
Affects Version/s: None
-
Component/s: hotspot
With AHS, G1 will determine a maximum heap size based on the environment, e.g.
- available RAM with uncompressed oops
- compressed oops boundary
This impacts the heap region size selected.
However, having a large maximum heap does not automatically imply that the application will use it. A large heap region size can be bad on small actual heaps (eg a few 100m), so G1 will need to update heap region size ergonomics to not size heap regions too large.
At the same time it should not be too small (on applications actually using lots of memory, with lots of parallelism) as this might decrease performance due to smaller TLABs and more heap allocation region switches.
Some idea:
* see how many threads we have, only if there are "many" threads to use small regions are costly
* limit heap region size particularly if there are "no bounds" by the user
- available RAM with uncompressed oops
- compressed oops boundary
This impacts the heap region size selected.
However, having a large maximum heap does not automatically imply that the application will use it. A large heap region size can be bad on small actual heaps (eg a few 100m), so G1 will need to update heap region size ergonomics to not size heap regions too large.
At the same time it should not be too small (on applications actually using lots of memory, with lots of parallelism) as this might decrease performance due to smaller TLABs and more heap allocation region switches.
Some idea:
* see how many threads we have, only if there are "many" threads to use small regions are costly
* limit heap region size particularly if there are "no bounds" by the user
- relates to
-
JDK-8353716 G1: AHS work umbrella
-
- Open
-