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 

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

Reply via email to