On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee <jver...@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
