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

[Jorn Vernee]

On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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 end 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, and we invoke it in our code in 4. 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).
>
>> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated.
> 
> My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM.
> 
> In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly.
> 
> So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways.

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).

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

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