RFR: JDK-8320368: Per-CPU optimization of Klass range reservation [v10]

[Andrew Haley]

On Fri, 24 Nov 2023 14:17:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> In `Metaspace::reserve_address_space_for_compressed_classes`, we reserve space for the future Klass range. We place the Klass range somewhere that allows us to use "good" narrow Klass decoding later when initializing the encoding scheme.
>> 
>> Narrow Klass decoding is inherently CPU-specific, so doing this in shared coding is awkward. It leads to many ifdefs, vague code comments that are difficult to explain, and missed optimizations. 
>> 
>> There are common patterns: 
>> - all platforms benefit from unscaled encoding so trying to reserve <4GB for CDS=off is worthwhile. 
>> 
>> But there are more differences than one would think:
>> - some platforms (s390, riscv) benefit from reservation < 4GB even with CDS=on since a 32-bit immediate requires fewer instructions
>> - some platforms (aarch64) don't benefit from zero-based encoding, so no need to try that
>> - some platforms benefit from optimizing the base for 16-bit moves (PPC, s390, aarch64) or for other immediate formats (riscv)
>> 
>> It would be much better to have this section per CPU so that every CPU can implement its perfect, well documented version. A bit of code duplication is a good price for code clarity.
>> 
>> -------------
>> 
>> This patch splits out `Metaspace::reserve_address_space_for_compressed_classes` into five variants, one per CPU (moving the code to CompressedKlassPointers); it also splits out `CompressedKlassPointers::initialize` into two variants, one for aarch64, one for all other platforms. 
>> 
>> Changes per-CPU:
>> 
>> #### aarch64:
>> 
>> Don't attempt to reserve for zero-based encoding; since lsl is not faster than movk. We reserve for movk mode right away if reserve for unscaled fails or if CDS=on.
>> 
>> We also add a last-ditch attempt to reserve optimized for movk via over-alignment. We only do this on aarch64 to prevent errors like this one JDK-8318119: "Invalid narrow Klass base on aarch64 post 8312018"
>> 
>> Since we don't want zero-based encoding, we need an aarch64-specific version for `CompressedKlassPointers::initialize()`
>> 
>> #### riscv:
>> 
>> We attempt to reserve at a "good" base that has only bits set either in [12..32), [32, 44) or in [44, 64).
>> 
>> #### s390:
>> 
>> We attempt to allocate < 4GB unconditionally.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   switch off AIX tests since AIX does not support CDS

AArch64 looks good. One question, though: did you ever find the root cause of JDK-8318119? Without that, how do we know we've fixed it?

-------------

PR Review: https://git.openjdk.org/jdk/pull/16743#pullrequestreview-1749358976