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