[foreign-memaccess+abi] RFR: 8270851: Logic for attaching/detaching native threads could be improved [v2]

[David Holmes]

On Tue, 29 Mar 2022 13:51:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The problem here is that our caller is plain native code which has no idea that it's calling into Java. So, I don't think we can realistically propagate "back up the stack". Even if we have a previous Java frame (which is not always the case), 'skipping' all the native code in between, which might contain critical cleanups, doesn't seem like a good move if we want to leave the application in a runnable/stable state after the error has been handled.
>> 
>> I think crashing is the safest thing we can do right now. Maybe in case of an exception, we could also dispatch to a user-defined exception handler installed through the Linker API, which could then decide what to do. But, tbh, I'm a little skeptical that such a solution could do something more useful than crashing, or just re-trying the attach.
>
> I tend to agree - only actionable observation is that reporting the JNI error code, as David noted, is probably useless.

I admit I don't know what the full context is here but at some level you have a piece of external code calling something and expecting something useful to happen as a result. I would have expected that API, whatever it is, to have some way of indicating that an error occurred and that the "something useful" did not in fact happen. If the initial code does not even know it is calling into a JVM I would expect it to be pretty miffed when the JVM decides to blow away the entire process due to an incidental issue the JVM had! 

Even if aborting is your only option I don't think a guarantee, with ensuing JVM core dump and hs_err file, is the way to go about it. I would not want to be fielding bug reports against the JVM in such a case.

Cheers.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/570