JDK-8353174 : Clean up thread register handling after 32-bit x86 removal
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-03-28
  • Updated: 2025-04-11
  • Resolved: 2025-04-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b18Fixed
Related Reports
Relates :  
Description
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.
Comments
Changeset: 6df34c36 Branch: master Author: Aleksey Shipilev <shade@openjdk.org> Date: 2025-04-09 07:28:47 +0000 URL: https://git.openjdk.org/jdk/commit/6df34c361e0d1b6fe90ca97c1aaa56e57a86d12c
09-04-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24323 Date: 2025-03-31 10:19:57 +0000
08-04-2025