On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
>> 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?) SOE (of the Java exception kind) is not specially handled right now. I think the same rule applies there: we can't unwind or return to native frames (at least not without some guidance from the user). I've filed an issue here to capture some of the discussion: https://bugs.openjdk.java.net/browse/JDK-8286761 ------------- PR: https://git.openjdk.java.net/jdk/pull/7959
