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: 


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

Reply via email to