[foreign-memaccess+abi] RFR: 8301261: Add linker option for specifying uncaught exception handler

[Jorn Vernee]

On Fri, 3 Feb 2023 15:50:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds the ability to specify an uncaught exception handler for an upcall stub, and changes the uncaught exception handling code to delegate to the thread's installed uncaught exception handler when no handler is specified as well, which will also allow setting a system-wide uncaught exception handler.
>> 
>> For the tests: I've refactored TestUpcallException a bit. Previously the test code was found in a separate class (ThrowingUpcall). I've removed this class and moved the code into nested classes of TestUpcallException instead. Then I've added new test cases for testing the uncaught exception handler.
>> 
>> I also noticed that we were setting the wrong system property to control binding recipe specialization in several tests (I thought I fixed this before, but it might have been undone by a merge...). I've fixed these to set the right property, and that also revealed a small bug in the interpreted version of the UnboxAddress binding, where we weren't properly reject heap segments. I've fixed that as well.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 185:
> 
>> 183:             // where the caller is an upcall stub.
>> 184:             Thread.UncaughtExceptionHandler uncaughtExceptionHandler = callingSequence.uncaughtExceptionHandler();
>> 185:             MethodHandles.Lookup defineClassLookup = uncaughtExceptionHandler != null
> 
> Perhaps we could make this more regular by having an handler in all cases? E.g. the default handler could rethrow?

The default handler would be the one installed on the thread when we encounter an exception. I don't think we can return that one here though, since someone might link the upcall stub, and then afterwards set the thread's default exception handler.

The handler specified as a linker option can be used to override that handler on a per upcall stub basis, if wanted. This is needed also in cases where native code spawns a new thread, and perhaps a user doesn't have an opportunity to set the default exception handler for that thread (before an exception is thrown).

> test/jdk/java/foreign/TestUpcallException.java line 78:
> 
>> 76:     public static class NonVoidUpcallRunner extends ExceptionRunnerBase {
>> 77:         public static void main(String[] args) throws Throwable {
>> 78:             MethodHandle handle = MethodHandles.identity(int.class);
> 
> I'm not 100% sure that building these complex method handle chains is better than just having two throwing methods in the code - one with zero arguments and one with one argument (int) ?

Yeah, that seems simpler.

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

PR: https://git.openjdk.org/panama-foreign/pull/777