On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: >> https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: > >> 304: intptr_t exception_handler_offset = __ pc() - start; >> 305: >> 306: // Native caller has no idea how to handle exceptions, > > Can you elaborate, please, how it is expected to work in presence of > asynchronous exceptions? I'd expect to see a code which unconditionally > clears pending exception with an assertion that verifies that the exception > is of expected type. We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959
