This is a similar issue as fixed with JDK-8237859 and follow-up issues: Data that is dependent on a hoisted check is rewired to the zero-trip-guard before the loop but not updated when further splitting the loop into sub loops.

While JDK-8237859 was caused by Loop Predication, we can now observe the same problem for Range Check Elimination when removing a range check from the main-loop. In order to observe the problem, we require the main-loop to be peeled again which is not that common.

This can lead to a non-observable out-of-bounds access at runtime when an access for an actually unreachable sub loop floats above the corresponding zero-trip-guard for that sub loop.

The attached Test.java crashes intermittently and reveals the problem (run with -XX:+StressGCM which ensures that sometimes a load is indeed floating above the zero-trip-guard for the sub loop).

The easiest fix is to not pin data at the zero-trip-guard at runtime but at the additionally added Template Assertion Predicates. This will ensure that the data is properly updated when further splitting the main-loop with Loop Peeling and possible follow-up loop splitting optimizations.

Long term, we could think about whether Assertion Predicates are still needed or whether TypeNode::make_paths_from_dead() + a different control update mechanism for data nodes completely takes care of keeping control and data in sync and correctly updating data.

I propose, however, to go with an Assertion Predicates fix for now and revisit this question again separately.


#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f6febdba0c8, pid=368215, tid=368216
#
# JRE version: Java(TM) SE Runtime Environment (27.0+12) (fastdebug build 27-ea+12-1020)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 27-ea+12-1020, compiled mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# J 103 c2 Test.test()V (138 bytes) @ 0x00007f6febdba0c8 [0x00007f6febdb9d80+0x0000000000000348]
.............
Command Line: -Xcomp -XX:CompileCommand=compileonly,Test*::test* -XX:+StressGCM -XX:-UseLoopPredicate -XX:+StressGCM -XX:+UseZGC --add-modules=ALL-DEFAULT jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher Test.java
............

Stack: [0x00007f7000a25000,0x00007f7000b25000], sp=0x00007f7000b23360, free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 103 c2 Test.test()V (138 bytes) @ 0x00007f6febdba0c8 [0x00007f6febdb9d80+0x0000000000000348]
j Test.main([Ljava/lang/String;)V+12
j java.lang.invoke.LambdaForm$DMH+0x000000000806c000.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@27-ea
j java.lang.invoke.LambdaForm$MH+0x0000000008151400.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@27-ea
j java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@27-ea
j jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@27-ea
j jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@27-ea
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@27-ea
j com.sun.tools.javac.launcher.SourceLauncher.execute(Lcom/sun/tools/javac/launcher/MemoryContext;[Ljava/lang/String;)Ljava/lang/Class;+496 jdk.compiler@27-ea
j com.sun.tools.javac.launcher.SourceLauncher.run([Ljava/lang/String;[Ljava/lang/String;)Lcom/sun/tools/javac/launcher/Result;+62 jdk.compiler@27-ea
j com.sun.tools.javac.launcher.SourceLauncher.main([Ljava/lang/String;)V+14 jdk.compiler@27-ea
v ~StubRoutines::call_stub_stub (stub gen) 0x00007f6feb6605f8
V [libjvm.so+0x10f908e] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x50e
V [libjvm.so+0x127cd60] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x420
V [libjvm.so+0x1280986] jni_CallStaticVoidMethod+0x216
C [libjli.so+0x3c1a] invokeStaticMainWithArgs+0x4a
C [libjli.so+0x4cf8] JavaMain+0xf08
C [libjli.so+0x8099] ThreadJavaMain+0x9