Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8268343

Upstream: 8267989: Exceptions thrown during upcalls should be handled

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P3 P3
    • 17
    • tools
    • None
    • behavioral
    • minimal
    • Hide
      This is a change in behavior of an API that is currently incubating. Users that explicitly threw an exception during an upcall in order to catch it once control returns to Java code will have to find another exception handling approach. (as outlined in the CSR body, this way of handling exceptions is unsafe).
      Show
      This is a change in behavior of an API that is currently incubating. Users that explicitly threw an exception during an upcall in order to catch it once control returns to Java code will have to find another exception handling approach. (as outlined in the CSR body, this way of handling exceptions is unsafe).
    • Java API
    • JDK

      Summary

      Uniformly handle exceptions thrown during panama upcalls by printing their stack trace and unconditionally exiting the VM.

      Problem

      Currently, exceptions thrown during upcalls are either handled by raising a fatal VM error, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode.

      Both of these are bad. The former because a stack trace is not printed and the error message that appears is user hostile. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold.

      Solution

      Add uniform exception handling for both of these cases.

      Specification

      --- a/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
      +++ b/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java
      @@ -214,8 +214,15 @@ static SymbolLookup systemLookup() {
            * Allocates a native stub with given scope which can be passed to other foreign functions (as a function pointer);
            * calling such a function pointer from native code will result in the execution of the provided method handle.
            *
      -     * <p>The returned memory address is associated with the provided scope. When such scope is closed,
      +     * <p>
      +     * The returned memory address is associated with the provided scope. When such scope is closed,
            * the corresponding native stub will be deallocated.
      +     * <p>
      +     * The target method handle should not throw any exceptions. If the target method handle does throw an exception,
      +     * the VM will exit with a non-zero exit code. To avoid the VM aborting due to an uncaught exception, clients
      +     * could wrap all code in the target method handle in a try/catch block that catches any {@link Throwable}, for
      +     * instance by using the {@link java.lang.invoke.MethodHandles#catchException(MethodHandle, Class, MethodHandle)}
      +     * method handle combinator, and handle exceptions as desired in the corresponding catch block.
            *
            * @param target   the target method handle.
            * @param function the function descriptor.

            jvernee Jorn Vernee
            jvernee Jorn Vernee
            Paul Sandoz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: