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