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

[Maurizio Cimadamore]

On Wed, 30 Mar 2022 07:15:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

I think aborting is the only option. The flow starts with some native call made by Java code. At some point the native code upcalls back into Java, and, for some reason, attaching a thread fails. When this failure occurs we are deep inside a native library. Popping back until we reach some Java frame seems undesirable (what happens to all the native code in the middle?). As I pointed out yesterday, we have a similar situation when the *Java* code inside an upcall fails with some exception: but in that case at least we have a thread, so we can dump a stack trace, which makes it "look" like a normal exception (but it's not, in the sense that it cannot be caught by the Java code - as the VM exits after dumping the stack trace).
This is worse, as we can't even dump the stack trace (as we have no thread), so the best we can do is to dump some message, and then exit. I agree that generating a VM dump is too much, and we should scale that back. But I don't think there is a meaningful way to recover (as the recovery would have to happen inside the C code, which Panama cannot, by definition, control).

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

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