Since narrow Klass decoding is inherently CPU-specific (see the various variants of MacroAssembler::decode_klass()), this is awkward. It leads to many ifdefs, awkward, vague code comments that are difficult to grok, and missed optimization opportunities. It would be much better to have this section per CPU so that every CPU can implement its own perfect and perfectly documented version. A bit of code duplication is a good price for code clarity.
(This results from lengthy discussions with Andrew Haley and many exhausting attempts to get this shared coding into a form that fits all CPUs and satisfies all reviewers).
If we do that, we can do more targeted optimizations per CPU. For example:
- on RiscV, we could go for a 64-bit immediate that only needs a single instruction to load
- on both RiscV and s390, reserving < 4GB should be done unconditionally, regardless if we run with CDS or not. This is because even if CDS is enabled and we cannot use zero-based encoding, such an immediate is still cheaper to load.
- on Aarch64, attempting to reserve for zero-based encoding (base=0 shift>0) is not necessary; lsl costs as much as a single movk (and I was told it was historically more expensive), so we should go for movk mode right away if unscaled is not an option
- duplicates
-
JDK-8320757 java --version crashes immediately on raspberry pi aarch64
-
- Closed
-
-
JDK-8318119 Invalid narrow Klass base on aarch64 post JDK-8312018
-
- Closed
-
- relates to
-
JDK-8321063 AArch64: Zero build fails after JDK-8320368
-
- Resolved
-
-
JDK-8323556 CDS archive space addresses should be randomized with ArchiveRelocationMode=1
-
- Closed
-
-
JDK-8329656 assertion failed in MAP_ARCHIVE_MMAP_FAILURE path: Invalid immediate -5 0
-
- Resolved
-
-
JDK-8323556 CDS archive space addresses should be randomized with ArchiveRelocationMode=1
-
- Closed
-
-
JDK-8312018 Improve reservation of class space and CDS
-
- Resolved
-
-
JDK-8320382 Remove CompressedKlassPointers::is_valid_base()
-
- Resolved
-