RFR: 8283689: Update the foreign linker VM implementation [v7]

[Jorn Vernee]

On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov <vlivanov at 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