On Thu, 12 May 2022 09:24:23 GMT, Jorn Vernee <jver...@openjdk.org> wrote:

> Do nothing special for async exceptions. i.e. if they happen anywhere between 
> 1. and 6. they will end up in one of the fallback handlers and the VM will be 
> terminated.

My understanding is that if they materialize while we're executing the upcall 
Java code, if that code has a try/catch block, we will go there, rather than 
crash the VM.

In other words, IMHO the only problem with async exception is if they occur 
_after_ the Java user code has completed, because that will crash the Java 
adapter, this preventing it from returning to native call cleanly.

So, either we disable async exceptions during that phase (e.g. after user code 
has executed, but before we return back to native code), or we just punt and 
stop. Since this seems like a corner^3 case, and since there are also other 
issue with upcalls that can occur if other threads do not cooperate (e.g. an 
upcall can get stuck into an infinite safepoint if the VM exits while an async 
native thread runs the upcall), and given that obtaining a linker is a 
restricted operation anyway, I don't think we should bend over backwards to try 
to add 1% more safety to something that's unavoidably sharp anyways.


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

Reply via email to