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

[Jorn Vernee]

On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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.

Discussed this with Maurizio as well. 

My understanding is as follows:
1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint
2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate).
3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly.
4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state.

As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think.

(@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959