On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee <jver...@openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306:
>>> 304:   intptr_t exception_handler_offset = __ pc() - start;
>>> 305: 
>>> 306:   // Native caller has no idea how to handle exceptions,
>> Can you elaborate, please, how it is expected to work in presence of 
>> asynchronous exceptions? I'd expect to see a code which unconditionally 
>> clears pending exception with an assertion that verifies that the exception 
>> is of expected type.
> 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 
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?)


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

Reply via email to