JDK-8327201 : C2: Uninitialized VLoop::_pre_loop_end after JDK-8324890
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 23
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-03-04
  • Updated: 2024-03-04
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 23
23Unresolved
Related Reports
Relates :  
Description
JDK-8324890 refactored `_pre_loop_end` field from `CountedLoopNode` to `VLoop`, but missed moving the initialization from relevant constructor:
 https://github.com/openjdk/jdk/commit/232d13688596e9a3c1145ee456dd5a6f7cd1223d#diff-03984204866fcf34c14cb3e5b8ad40348cd60f31af7c937ce6ef7b84e8ea1c69L241

SonarCloud now complains about that field in VLoop:
 1 uninitialized field at the end of the constructor call

The bug looks innocuous so far, but it would potentially skip the assert and return garbage here:

```
  CountedLoopEndNode* pre_loop_end() const {
    assert(cl()->is_main_loop(), "only main loop can reference pre-loop");
    assert(_pre_loop_end != nullptr, "must have found it");
    return _pre_loop_end;
  };
```
Comments
Joshua did not take it himself, I just proactively assigned this to one of our C2 engineers :)
04-03-2024

[~jcao] thanks for taking this one. Looks like a one-line fix.
04-03-2024

ILW = Missing default initialization of field, code path not used, no workaround = LLH = P5
04-03-2024