On Thu, 12 May 2022 03:32:15 GMT, David Holmes <dhol...@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
