JDK-8367667 : C2: enforce address type consistency
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-09-15
  • Updated: 2025-09-15
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8349930 - C2: verify memory liveness invariants after scheduling
Relates :  
JDK-8347901 - C2 should remove unused leaf / pure runtime calls
Relates :  
JDK-8350864 - C2: verify structural invariants of the Ideal graph
Description
Introduce verification code to ensure that C2 nodes have a non-null address type (Node::adr_type()) if they use and/or define memory, and a null address type otherwise. Whether a node uses or defines memory can be tested by checking the type of its inputs and outputs. Ensure the current C2 representation is consistent at key compilation points (e.g. at the end of platform-independent optimizations, or before scheduling, where the address type is used for alias analysis).

This RFE is motivated by JDK-8347901, which (unnoticedly) changed the address type of the pure call nodes after final graph reshaping: before the change, adr_type() was set to nullptr; after the change, it is set to rawptr:BotPTR. This effect is likely harmless, but it would be good to have a mechanism to catch and prevent such inconsistencies.