RFR: 8323497: On x64, use 32-bit immediate moves for narrow klass base if possible [v6]

[Aleksey Shipilev]

On Thu, 22 May 2025 13:41:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> On x64, we always use the long form of mov immediate to load the klass base into a register. If the klass base fits into 32 bits, we could use the short form and save four instruction bytes. 
>> 
>> Before: mov uses 10 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007f8b089e51c4:   movabs $0x82000000,%r11
>>    37   0x00007f8b089e51ce:   add    %r11,%r10
>> 
>> 
>> Now: mov uses 6 instruction bytes:
>> 
>> 
>>    35  ;; decode_klass_not_null
>>    36   0x00007fbe609e51c4:   mov    $0x82000000,%r11d
>>    37   0x00007fbe609e51ca:   add    %r11,%r10
>> 
>> 
>> Note that this optimization does not depend on zero-based addressing, and therefore we change class space reservation: we now always look in low-address regions first.
>> 
>> ----------
>> 
>> Tests: tier1 (GHA), tier 2 on x64 linux
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix COH

All right, I have more questions (unfortunately) :) See below.

Also, generic question. This handles decoding paths, should we also do this in `MacroAssembler::encode_klass*` and friends?

src/hotspot/cpu/x86/compressedKlass_x86.cpp line 41:

> 39:   result = reserve_address_space_X(0, nth_bit(32), size, Metaspace::reserve_alignment(), aslr);
> 40: 
> 41:   if (result == 0 && optimize_for_zero_base) {

Should be `result == nullptr`.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5444:

> 5442:   }
> 5443:   if (CompressedKlassPointers::base() != nullptr) {
> 5444:     // Note: we use movptr to uses a 32-bit mov if the base is small enough

I think these "32-bit mov" comments are not really useful here. We also do not really know what macroAssembler would do with these. We just put the "machine pointer" in there, and let macroAssembler do the right thing.

test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java line 103:

> 101:             if (CDS) {
> 102:                 // We always try to allocate below 4 GB.
> 103:                 output.shouldContain("reserve_between (range [0x0000000000000000-0x0000000100000000)");

OK, but `!CDS` case, should we do the same?

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

PR Review: https://git.openjdk.org/jdk/pull/17340#pullrequestreview-2861902764
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r2102982221
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r2103017436
PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r2103015674