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

[Jorn Vernee]

On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :)

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

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