ChengJin01
commented
8 months ago This is a newly added test suite in JDK22 which we will need to investigate to see what happens in there. Will spend time later this week to take a look if possible.
Closed pshipton closed 7 months ago
ChengJin01
commented
8 months ago This is a newly added test suite in JDK22 which we will need to investigate to see what happens in there. Will spend time later this week to take a look if possible.
ChengJin01
commented
7 months ago 1) Looking at the test suite at https://github.com/ibmruntimes/openj9-openjdk-jdk22/blob/openj9/test/jdk/java/foreign/TestStubAllocFailure.java
@Test
public void testUpcallAllocFailure() throws IOException, InterruptedException {
runInNewProcess(UpcallRunner.class, true, List.of("-XX:ReservedCodeCacheSize=3M"), List.of())
.shouldNotHaveExitValue(0) <-------- verify whether the return code != 0
.shouldNotHaveFatalError();
}
@Test
public void testUDowncallAllocFailure() throws IOException, InterruptedException {
runInNewProcess(DowncallRunner.class, true, List.of("-XX:ReservedCodeCacheSize=3M"), List.of())
.shouldNotHaveExitValue(0) <-------- verify whether the return code != 0
.shouldNotHaveFatalError();
}it indicates the intention of the downcall & upcall test is to check whether the test ends up with non-zero code when specifying -XX:ReservedCodeCacheSize=3M which is the maximum size for the Hotspot JIT compiler's code cache, as explained at https://docs.oracle.com/javase/8/embedded/develop-apps-platforms/codecache.htm, That being said, the test suite is intended for Hostpot which is meaningless as the underlying FFI implementation in OpenJ9 is totally different from Hotspot.
2) Secondly, the failing outputs in the description happened in the upcall test at https://github.com/ibmruntimes/openj9-openjdk-jdk22/blob/687a1453366566440768237f7c69361b2ec21406/test/jdk/java/foreign/TestStubAllocFailure.java#L66
public static class UpcallRunner extends NativeTestHelper {
public static void main(String[] args) throws Throwable {
FunctionDescriptor descriptor = FunctionDescriptor.ofVoid();
MethodHandle target = MethodHandles.lookup().findStatic(UpcallRunner.class, "target", descriptor.toMethodType());
while (true) { <------ an infinite loop of allocating the upcall thunk memory in OpenJ9
LINKER.upcallStub(target, descriptor, Arena.ofAuto());
}
}which was in the process of allocating the upcall memory for the thunk in OpenJ9 unless there was no native memory available for allocation as indicated in debugging the upcall test:
Thread 2 (Thread 0x7f1b3ea09700 (LWP 573053)):
#0 0x00007f1b3e4afbe6 in VM_AtomicSupport::nop () at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/omr/include_core/AtomicSupport.hpp:166
#1 0x00007f1b3e4afa29 in omrthread_spinlock_acquire (self=0x7f1b380071a0, monitor=0x7f1b38080938) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/omr/thread/common/threadhelpers.cpp:106
#2 0x00007f1b3e4a6c8a in monitor_enter_three_tier (self=0x7f1b380071a0, monitor=0x7f1b38080938, isAbortable=0) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/omr/thread/common/omrthread.c:3998
#3 0x00007f1b3e4a6930 in omrthread_monitor_enter (monitor=0x7f1b38080938) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/omr/thread/common/omrthread.c:3837
------> #4 0x00007f1b3e5a96df in allocateUpcallThunkMemory (data=0x7f1b38e1c830) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/UpcallThunkMem.cpp:70
#5 0x00007f1b3e78797e in createUpcallThunk (metaData=0x7f1b38e1c830) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/xa64/UpcallThunkGen.cpp:947
#6 0x00007f1b3e58194f in OutOfLineINL_openj9_internal_foreign_abi_InternalUpcallHandler_allocateUpcallStub (currentThread=0x1aa00, method=0x3098b0) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/OutOfLineINL_openj9_internal_foreign_abi_InternalUpcallHandler.cpp:144
#7 0x00007f1b3e5ef7df in VM_BytecodeInterpreterCompressed::outOfLineINL (this=0x7f1b3ea08740, _sp=@0x7f1b3ea086c0: 0x1308e0, _pc=@0x7f1b3ea086c8: 0x7f1b3e8715a0 <VM_BytecodeInterpreterCompressed::nativeReturnBytecodePC(unsigned long*&, unsigned char*&, J9ROMMethod*)::returnFromNativeBytecodes+32> "\270") at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/BytecodeInterpreter.hpp:5564
#8 0x00007f1b3e604524 in VM_BytecodeInterpreterCompressed::run (this=0x7f1b3ea08740, vmThread=0x1aa00) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/BytecodeInterpreter.hpp:11082
#9 0x00007f1b3e5d73f6 in bytecodeLoopCompressed (currentThread=0x1aa00) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/BytecodeInterpreter.inc:112
#10 0x00007f1b3e78a0a2 in c_cInterpreter () at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/build/linux-x86_64-server-release/vm/runtime/vm/xcinterp.s:158
#11 0x00007f1b3e4ea0ae in runCallInMethod (env=0x1aa00, receiver=0x0, clazz=0x130ee0, methodID=0x7f1b38273e18, args=0x7f1b3ea08d58) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/callin.cpp:1174
#12 0x00007f1b3e53242f in gpProtectedRunCallInMethod (entryArg=0x7f1b3ea08cf0) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/jnicsup.cpp:300
#13 0x00007f1b3e7a4b98 in signalProtectAndRunGlue (portLibrary=0x7f1b3e9860e0 <j9portLibrary>, userData=0x7f1b3ea08ca0) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/util/jniprotect.c:45
#14 0x00007f1b3e2ddfaa in omrsig_protect (portLibrary=0x7f1b3e9860e0 <j9portLibrary>, fn=0x7f1b3e7a4b68 <signalProtectAndRunGlue>, fn_arg=0x7f1b3ea08ca0, handler=0x7f1b3e527981 <structuredSignalHandler>, handler_arg=0x1aa00, flags=506, result=0x7f1b3ea08c88) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/omr/port/unix/omrsignal.c:425
#15 0x00007f1b3e7a4d01 in gpProtectAndRun (function=0x7f1b3e5323ce <gpProtectedRunCallInMethod(void*)>, env=0x1aa00, args=0x7f1b3ea08cf0) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/util/jniprotect.c:78
#16 0x00007f1b3e5329d6 in gpCheckCallin (env=0x1aa00, receiver=0x0, cls=0x130ee0, methodID=0x7f1b38273e18, args=0x7f1b3ea08d58) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/jnicsup.cpp:488
#17 0x00007f1b3e5311ef in callStaticVoidMethod (env=0x1aa00, cls=0x130ee0, methodID=0x7f1b38273e18) at /root/docker_openj9/jchau_ffi/openj9-openjdk-jdk22/openj9/runtime/vm/jnicgen.c:384
#18 0x00007f1b3ec45459 in invokeStaticMainWithArgs (env=0x0, mainClass=0xf9df0a50, mainArgs=0xf9df0a78) at src/java.base/share/native/libjli/java.c:486
#19 0x00007f1b3ec46445 in JavaMain (_args=<optimized out>) at src/java.base/share/native/libjli/java.c:691
So the test failure with upcall was actually neither a deadlock nor hang but a timeout triggered by the infinite loop of the native memory allocation for the upcall thunk. Changing the loop in the upcall test with an fixed count will get the test passed (e.g. for (int i =0; i < xxx; i++) {....})
Given the test is only intended for Hotspot/JIT, I'd suggest to permanently exclude the test suite.
pshipton
commented
7 months ago Pls remove the "test excluded" label when adding "perm excluded".
pshipton
commented
7 months ago Does this mean we can also ~remove this issue from the milestone plan and~ close it?
ChengJin01
commented
7 months ago Does this mean we can also remove this issue from the milestone plan and close it?
Yes as there is nothing else for us to do in the test.
pshipton
commented
7 months ago I guess we don't need to remove from the milestone if we are closing it.
https://openj9-jenkins.osuosl.org/job/Pipeline-Build-Test-JDK22/10/ - all platforms
https://openj9-jenkins.osuosl.org/job/Test_openjdk22_j9_sanity.openjdk_aarch64_linux_Nightly_testList_1/8/ https://openj9-jenkins.osuosl.org/job/Test_openjdk22_j9_sanity.openjdk_aarch64_linux_Nightly_testList_2/8/ jdk_foreign java/foreign/TestStubAllocFailure.java
https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Test/Test_openjdk22_j9_sanity.openjdk_aarch64_linux_Nightly_testList_1/8/openjdk_test_output.tar.gz
@ChengJin01 fyi