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

Andrew Haley aph at openjdk.org
Tue Feb 20 09:26:55 UTC 2024


On Thu, 11 Jan 2024 11:30:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> With the new movptr variant, things look good:
>> 
>> < 2g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007fcb608681c4:   mov    $0x18000000,%r11d
>> 0x00007fcb608681c4:   41 bb 00 00 00 18 
>>   0x00007fcb608681ca:   add    %r11,%r10
>> 0x00007fcb608681ca:   4d 03 d3 
>> 
>> 
>> < 4g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007f382c8681c4:   mov    $0x85000000,%r11d
>> 0x00007f382c8681c4:   41 bb 00 00 00 85 
>>   0x00007f382c8681ca:   add    %r11,%r10
>> 0x00007f382c8681ca:   4d 03 d3 
>> 
>> 
>>> 4g
>> 
>> 
>>  ;; decode_klass_not_null
>>   0x00007fd8908681c4:   movabs $0x7fd7b6000000,%r11
>> 0x00007fd8908681c4:   49 bb 00 00 00 b6 d7 7f 00 00 
>>   0x00007fd8908681ce:   add    %r11,%r10
>> 0x00007fd8908681ce:   4d 03 d3 
>> 
>> 
>> I assume if the 32-bit mov variants were to use non-Rxx registers, the REX prefix could also be omitted? Giving us another byte back.
>> 
>> I'll run tests with the new variant.
>
> BTW, I think it would be useful for PrintAssembly to also optionally print the raw bytes in addition to the decoded instruction. It certainly helps me understanding stuff. Do you agree? If yes, I'll prepare a patch.

I'm pretty marginal on this. If I ever have needed to see bytes, I've used the debugger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17340#discussion_r1495493867


More information about the hotspot-dev mailing list