RFR: 8283689: Update the foreign linker VM implementation [v7]

[Jorn Vernee]

On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov <vlivanov at 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