On Thu, 12 May 2022 17:26:44 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. > > Ok. Then, if no one objects, I will leave this area as-is for now. (and > perhaps come back to this issue in the future, if it becomes more pressing). > > (I'll also note that this issue already exists in the current code that's in > mainline. So, it seems fair to address this as a followup as well, if needed). I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. >From reliability perspective, I find it important to gracefully handle such >corner cases. But I'm fine with addressing the problem separately. As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959
