KONNO Kazuhiro

> InaccessibleAddress=006100760061006A It looks like a string "java" in little endian. `leftKey` passed to `classAndLoaderHashEqualFn()` is broken.

The crash above occurred at accessing `prev->_next->_priority` in `TR::CompilationInfo::queueEntry()` that is inlined in `TR::CompilationInfoPerThread::requeue()` below. `prev->_next` (= 0x9EF9400281F94006 in x10) is broken. https://github.com/eclipse-openj9/openj9/blob/81d749041b56ad9f91da34c04c1e746a9d51b84b/runtime/compiler/control/CompilationThread.cpp#L5158 x9 seems to hold the value of...

The failure above with Symbol=old_slow_jitHandleInternalErrorTrap looks the same with #15518. Trying to access the address `[x10, #-40]`, and that crosses a page boundary, and no memory is allocated for the...

The failure above accesses load data from `[x9, #56]`, and `x9` is 0x0. It is in the constructor of `MM_IndexableObjectAllocationModel`. ``` cc200: d7 2c ff 97 bl 0x9755c cc204: 60...

It looks the same as #15518, again. Accessing `[x10, #-40]` crosses the page boundary, and no memory is mapped to the address. Segmentation fault as the result. > InaccessibleAddress=000000010F7FFFF8 >...

I got the exception "Invalid JIT return address" by running the "!stack" command against JIT Compilation Thread-004, as shown below. ``` > !threads !stack 0x10f809d00 !j9vmthread 0x10f809d00 !j9thread 0x12b816050 tid...

There were failures with `J9::Monitor::exit()` before, but this is the first case with `J9::Monitor::enter()`. The "this" object (`x0`) is NULL. Call path: `initThreadAfterCreation()` -> `TR::CompilationInfo::acquireCompMonitor()` -> `J9::Monitor::enter()`. `x20` points to...

Running jdmpview "!stack" command on "JIT Compilation Thread-000" gives the following output, which is similar to the one last week. ``` > !stack 0x12d882900 JNI call-in frame known but unhandled...

I see the following incomplete output in the javacore file for the Test_openjdk18_j9_extended.system_aarch64_mac_Nightly_testList_0/114 job above. It is a JIT Compilation Thread, and recursive calls to `ClassLoader.loadClass()`, which was observed in...

PR #15907 should fix this issue.