On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo <pchilanom...@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
