On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore <mcimadam...@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
