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
