Skip to content

8387252: [lworld] LoadFlattenedArrayStub may not consider the spill inserted by RA #2579

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zifeihan wants to merge 1 commit into from
+10 −3
Closed

8387252: [lworld] LoadFlattenedArrayStub may not consider the spill inserted by RA #2579

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions src/hotspot/share/c1/c1_LIRGenerator.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2380,6 +2380,7 @@ void LIRGenerator::do_LoadIndexed(LoadIndexed* x) {
} else {
LIR_Opr result = rlock_result(x, x->elt_type());
LoadFlattenedArrayStub* slow_path = nullptr;
LIR_Opr load_result = result;

if (x->should_profile() && x->array()->maybe_null_free_array()) {
profile_null_free_array(array, md, data);
Expand All @@ -2388,19 +2389,25 @@ void LIRGenerator::do_LoadIndexed(LoadIndexed* x) {
if (x->elt_type() == T_OBJECT && x->array()->maybe_flat_array()) {
assert(x->delayed() == nullptr, "Delayed LoadIndexed only apply to loaded_flat_arrays");
index.load_item();
// if we are loading from a flat array, load it using a runtime call
slow_path = new LoadFlattenedArrayStub(array.result(), index.result(), result, state_for(x, x->state_before()));
// Use a temporary for the conditional load so that the RA defines
// 'result' at the continuation point (after both paths merge).
// Otherwise, the RA may insert a spill at the load's def point
// (inside the conditional code), and the stub's continuation jump
// would skip that spill, leaving the spill slot stale.
load_result = new_register(T_OBJECT);

@TobiHartmann TobiHartmann Jun 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the rlock_result just above in line 2381 do exactly that?

@dean-long dean-long Jun 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to detect spills in conditional code at compile time.

I'm not convinced creating a new virtual register for "load_result" here is correct either. It moves the problem to a different virtual register, one that has a shorter lifetime that "result", but does that guarantee there won't be a spill? We are still setting a register in two different paths that are invisible to C1 LIR.

@TobiHartmann TobiHartmann Jun 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Dean. I think it's the same problem I described in JDK-8353851.

@TobiHartmann TobiHartmann Jun 26, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe setting LIRGenerator::set_in_conditional_code here like we do as mitigation in Load/StoreIndexed would help?

@zifeihan zifeihan Jun 27, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dean-long @TobiHartmann Hi, I'm so sorry for being late.
I think this is the same issue as JDK-8353851.

Maybe setting LIRGenerator::set_in_conditional_code here like we do as mitigation in Load/StoreIndexed would help?

I will try this fix.

@zifeihan zifeihan Jul 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe setting LIRGenerator::set_in_conditional_code here like we do as mitigation in Load/StoreIndexed would help?

Hi Tobias,
I tried this fix, but it didn't solve the current problem(Maybe I misunderstood something). The program still crashed.
If you have a better fix suggestion, i'd be happy to try it out.

fix patch:

diff --git a/src/hotspot/share/c1/c1_LIRGenerator.cpp b/src/hotspot/share/c1/c1_LIRGenerator.cpp
index 0227615241c..05b8677fc55 100644
--- a/src/hotspot/share/c1/c1_LIRGenerator.cpp
+++ b/src/hotspot/share/c1/c1_LIRGenerator.cpp
@@ -2390,8 +2390,8 @@ void LIRGenerator::do_LoadIndexed(LoadIndexed* x) {
       index.load_item();
       // if we are loading from a flat array, load it using a runtime call
       slow_path = new LoadFlattenedArrayStub(array.result(), index.result(), result, state_for(x, x->state_before()));
-      check_flat_array(array.result(), slow_path);
       set_in_conditional_code(true);
+      check_flat_array(array.result(), slow_path);
     }
 
     DecoratorSet decorators = IN_HEAP | IS_ARRAY;

@TobiHartmann TobiHartmann Jul 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right, I got confused here. This is the same place where we already added set_in_conditional_code to mitigate the issue. As JDK-8353851 explains, we were suspecting that this is not sufficient. The issue you are now observing proves that this is true - unfortunately. Any luck coming up with a reproducer on x64 / AArch64?

So we need a proper fix for JDK-8353851. @mhaessig did some prototyping there and might have some more details to share but I think it boils down to adding some kind of macro node to LIR that is expanded "late" so that the register allocator can not add spilling in-between. I.e. avoid branching in the LIR altogether.

@TobiHartmann TobiHartmann Jul 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what about closing this as duplicate of JDK-8353851 so that we don't track the same thing twice?

@zifeihan zifeihan Jul 1, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what about closing this as duplicate of JDK-8353851 so that we don't track the same thing twice?

Sure if we think this is a duplicate of JDK-8353851. Let me close this.

slow_path = new LoadFlattenedArrayStub(array.result(), index.result(), load_result, state_for(x, x->state_before()));
check_flat_array(array.result(), slow_path);
set_in_conditional_code(true);
}

DecoratorSet decorators = IN_HEAP | IS_ARRAY;
access_load_at(decorators, x->elt_type(),
array, index.result(), result,
array, index.result(), load_result,
nullptr, null_check_info);

if (slow_path != nullptr) {
__ branch_destination(slow_path->continuation());
__ move(load_result, result);
set_in_conditional_code(false);
}

Expand Down