In various places we attempt to place memory within a given address range:
- if CompressedOops is on, we try to place the heap within the lower 4 or 32g
- if CompressedClassPointers is on and we use CDS, we need to place Metaspace within the narrow class pointer range starting at the shared base address
- CompressedClassPointers is on and we do not use CDS, we'd like Metaspace to live within the lower 32g
All these cases could benefit from a smarter approach, which should be investigated:
- On Windows, we already have an API (win32::find_mapping) which uses VirtualQuery to check for existing mappings. That API could be used or a similar approach could be implemented to scan for suitable holes.
- On Linux, one could scan /proc/self/maps to find a suitable hole.
If that did not work, or we are on a platform other than Linux or Windows, one could still use a "ladder-approach" - attempting to blindly attach memory at specific intervals.
The benefit of this RFE would be a higher chance of getting "good" memory, usable e.g. for unscaled or zero-based oops mode. It also could make the coding less complex, e.g. in the combined CDS/metaspace allocation.
This API should be used, as a first step, to improve metaspace allocation when used in conjunction with CDS.
- if CompressedOops is on, we try to place the heap within the lower 4 or 32g
- if CompressedClassPointers is on and we use CDS, we need to place Metaspace within the narrow class pointer range starting at the shared base address
- CompressedClassPointers is on and we do not use CDS, we'd like Metaspace to live within the lower 32g
All these cases could benefit from a smarter approach, which should be investigated:
- On Windows, we already have an API (win32::find_mapping) which uses VirtualQuery to check for existing mappings. That API could be used or a similar approach could be implemented to scan for suitable holes.
- On Linux, one could scan /proc/self/maps to find a suitable hole.
If that did not work, or we are on a platform other than Linux or Windows, one could still use a "ladder-approach" - attempting to blindly attach memory at specific intervals.
The benefit of this RFE would be a higher chance of getting "good" memory, usable e.g. for unscaled or zero-based oops mode. It also could make the coding less complex, e.g. in the combined CDS/metaspace allocation.
This API should be used, as a first step, to improve metaspace allocation when used in conjunction with CDS.
- duplicates
-
JDK-8312018 Improve reservation of class space and CDS
- Resolved