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

[Patricio Chilano Mateo]

On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 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?)

If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation.

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

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