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

[Jorn Vernee]

On Tue, 29 Mar 2022 13:05:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> For errors that occurs inside the upcall, we generally try to print a stack trace - but in this case we're a bit of a limbo between native and Java - and we still don't have a Java thread - so I'm assuming that if something goes wrong here there's not much we can do to dress it up nicely and/or recover? I agree that printing out JNI error code seems over the top (and not very useful).
>> 
>> I note that this code has not changed, even in the foreign-preview branch, which contains a bunch of JVM cleanups. Maybe we can file a followup (but I'd like to understand better what you are proposing - and what options we have on the table).
>
> 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.

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

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