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

[Jorn Vernee]

On Thu, 12 May 2022 03:32:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that.
>
> NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code".

Okay, I see. I think I acted a little too hastily on this yesterday.  I'll revert the change that uses this blocking mechanism.

The stack more or less looks like this during an upcall:


| ---
| <younger frames> |
| ---
| <1: user define try block with exception handler (maybe)> |
| ---
| <2: user code start> |
| ---
| <3: method handle impl frames 1> |
| ---
| <4: upcall wrapper class with fallback handler 1> |
| ---
| <5: method handle impl frames 2> |
| ---
| <6: upcallk stub with fallback handler 2> |
| <7: unknown native code>
| ---
| <older frames> |


I think there are several options to address async exceptions:
1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will up in one of the fallback handlers and the VM will be terminated.
2. Block async exceptions in all code up from 6.
3. Somehow only block async exceptions only between 6. and 1. 
    I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point).

-------------

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