RFR: JDK-8320368: Per-CPU optimization of Klass range reservation [v6]
Fei Yang
fyang at openjdk.org
Thu Nov 23 05:10:12 UTC 2023
On Wed, 22 Nov 2023 16:26:28 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:
>
> remove stray newline
src/hotspot/cpu/riscv/compressedKlass_riscv.cpp line 41:
> 39: //
> 40: // A "good" base is, in this order:
> 41: // 1) only bits in A; this would be an address < 2KB, which is unrealistic on normal Linux boxes since
@tstuefe : Hi Thomas, thanks for considering riscv. A small question: is the`2KB` in the code comment a typo? Seems that it should be `4KB` instead :-)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16743#discussion_r1402920607
More information about the hotspot-dev
mailing list