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

[Maurizio Cimadamore]

On Tue, 29 Mar 2022 13:10:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I don't have a proposal, just querying the failure strategy. You would need to propagate the fact an error occurred back up to the user code to allow it to decide how to proceed, which would complicate the API.
>> 
>> There are no hooks for printing any stacktrace in the case where they occur in the Thread construction sequence. But -Xlog:exceptions would show them.
>
> 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.

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

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