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

[Maurizio Cimadamore]

On Wed, 1 Feb 2023 22:12:30 GMT, Jorn Vernee <jvernee 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/java/lang/foreign/Linker.java line 340:

> 338:          *          if an exception is thrown, but not caught, during an upcall}
> 339:          * <p>
> 340:          * Note that using a custom exception handler will not prevent the VM from exiting in the case of an uncaught

maybe use `@apiNote` here (or remove the "note").

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?

test/jdk/java/foreign/TestIllegalLink.java line 65:

> 63:     }
> 64: 
> 65:     @Test(dataProvider = "upcallOnlyOptions",

nice tests!

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) ?

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

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