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 


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

Reply via email to