RFR: JDK-8318119: Invalid narrow Klass base on aarch64 post 8312018
Thomas Stuefe
stuefe at openjdk.org
Sat Oct 21 04:51:05 UTC 2023
When reserving space for class space or the combined CDS+class space, provide a fallback on aarch64 when all prior attempts to reserve space failed. Now the logic goes like this:
1) (only if not CDS) attempt to reserve in low-address regions
2) attempt to reserve at a 32G-aligned address at randomized attach points within the whole of the available address space
3) (new) attempt to reserve 4G-aligned by using os::reserve_aligned.
(3) is similar to (2), but (2) may fail if we are very unlucky and the address space is very populated. The difference between (2) and (3) is that with (3), the kernel chooses the placement of the VMA, and we rely on ASLR to provide entropy.
The patch also fixes os::reserve_memory_aligned() to remove the assertion that *size* needs to be aligned. There is no need for that, and for large alignments this will blow up the required over-allocation size even further.
The patch also fixes up CompressedKlassPointers::is_valid_base(). The whole purpose of this function is to filter out possibly invalid base addresses when someone manually specifies SharedBaseAddress. The problem with this function is that the encoding base alone is not sufficient to determine its validity, since for that one needs to know the shift value too, and for that the boundaries of the future encoding range. I changed this function to give the best answer possible at that point, see comment.
-------------
Commit messages:
- JDK-8318119-Invalid-narrow-Klass-base-on-aarch64-post-8312018
Changes: https://git.openjdk.org/jdk/pull/16215/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16215&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8318119
Stats: 29 lines in 4 files changed: 15 ins; 0 del; 14 mod
Patch: https://git.openjdk.org/jdk/pull/16215.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/16215/head:pull/16215
PR: https://git.openjdk.org/jdk/pull/16215
More information about the hotspot-runtime-dev
mailing list