On Wed, 1 Jul 2026 05:17:16 GMT, Gui Cao <[email protected]> wrote:

>> @dean-long @TobiHartmann Hi, I'm so sorry for being late.
>> I think this is the same issue as 
>> [JDK-8353851](https://bugs.openjdk.org/browse/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.
>
>> 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;

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](https://bugs.openjdk.org/browse/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](https://bugs.openjdk.org/browse/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.

-------------

PR Review Comment: 
https://git.openjdk.org/valhalla/pull/2579#discussion_r3503542617

Reply via email to