JDK-8354062 : x86: Optimize stores of zero immediates with r12_heapbase
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • CPU: x86
  • Submitted: 2025-04-08
  • Updated: 2025-05-26
  • Resolved: 2025-05-26
Related Reports
Relates :  
JDK-8221249 - x86: make r12_heapbase register available when compressed oops do not require it
Description
X86 does not have zero register. Except that it does for Hotspot, when compressed oops are enabled and heap base is zero. C2 routinely uses R12 as zero register then. It makes the code considerably more compact.

We can do the same in MacroAssembler. This would target the stores of known zeroes, which are surprisingly frequent in C1, mostly for zeroing out various JavaThread slots, e.g. for exception handling.

(We explored, tangentially, freeing R12 when it is zero, only to see that some C2 match rules use it as zero registers, see JDK-8221249. I suspect code density is why I saw some weird regressions back then.)
Comments
This proves to be very fiddly. We sometimes call movptr(..., NULL_WORD) around assembler code that does not have r12_heapbase set up correctly (yet). For example, near the native calls, which are supposed to reinitialize the heap base later. This will be further complicated if/when AOT code would accept changing heapbases between training and production runs (likely with some sort of relocation record). The code density win is not as large to justify this and future complexity. I am going to attach the draft patch to this issue, and WNF it. Feel free to use it, if we ever reconsider.
26-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24519 Date: 2025-04-08 17:53:29 +0000
08-04-2025