RFR: 8353174: Clean up thread register handling after 32-bit x86 removal
Aleksey Shipilev
shade at openjdk.org
Tue Apr 8 18:10:17 UTC 2025
On Tue, 8 Apr 2025 18:04:11 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:
>> Various `MacroAssembler` methods have this code to support passing the thread register, and getting it if `noreg` is passed:
>>
>>
>> // determine java_thread register
>> if (!java_thread->is_valid()) {
>> #ifdef _LP64
>> java_thread = r15_thread;
>> #else
>> java_thread = rdi;
>> get_thread(java_thread);
>> #endif // LP64
>> }
>>
>>
>> This never happens after 32-bit x86 removal. x86_64 always uses r15_thread. We can clean those up.
>>
>> These are also the only major users of `MacroAssembler::get_thread` that we want to remove/rename to avoid falling into traps like [JDK-8353176](https://bugs.openjdk.org/browse/JDK-8353176).
>>
>>
>> Additional testing:
>> - [x] Linux x86_64 server fastdebug, `all`
>
> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 293:
>
>> 291:
>> 292: void get_vm_result (Register oop_result);
>> 293: void get_vm_result_2(Register metadata_result);
>
> NIT: Can you please try to find a better suffix than "_2"?
It is a cross-platform mess. I think we want to rename it in one shot, in a separate PR? Want to take it? This `_2` is basically for metadata, while "`_1`" is for oops.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24323#discussion_r2033770810
More information about the hotspot-dev
mailing list