Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b96

      Description

      This issue is for JEP 259: Stack-Walking API integration.

        Issue Links

          Activity

          Hide
          mchung Mandy Chung added a comment -
          There is a long discussion on the behavior of StackWalker::getCallerClass when there is no caller frame. This captures the alternatives considered. [1] describes the JDK use cases of getCallerClass and concludes that the user needs the ability to differentiate if there is no caller frame.

          The alternatives considered for getCallerClass to return when it’s called by the last frame on the stack (i.e. main() or from a JNI invoked method).

          1. Optional.empty
          2. null
          3. StackWalker.NoCaller.class
          4. last frame
          5. Thread.class
          6. throw an exception - not supported

          getCallerClass is intended for frameworks to find the caller on behalf.

          For 1-4, the caller-sensitive API will have to handle this corner case explicitly.
              Class<?> caller = walker.getCallerClass(); // #1 it will do Optional.orElse or something
              if (caller is present) {
                    // common path
                    :
              } else {
                    // need to decide what to do
              }

          #1 and #2 are a better option than #3 and #4 that it will get an exception if the user forgets to handle the no caller frame case.

          #5 returning Thread.class - the user can’t differentiate between no caller frame case vs Thread::run case.

          This API is intended for framework to use getting the caller and do the operation on behalf. It’s rare that such API is invoked from newly JNI attached thread. JDK caller-sensitive methods might be invoked via JNI attached thread and JDK is not going to use StackWalker::getCallerClass. The public static void main calling getCallerClass.

          #1, #2, #6 are the options to be chosen from.
          #1 incurs an extra object allocation but the common case always has a caller.
          #2 forces null check at every usage
          #6 the API expected to be invoked by JNI newly attached thread will have to call StackWalker::walk instead.

          IMO, #6 is the best approach such that the common cases are not impacted. If it's determined in the future that a need of a convenient method to find caller that may be absent, a new method could provide a new getCallerClassOrNull method in the future.
          Show
          mchung Mandy Chung added a comment - There is a long discussion on the behavior of StackWalker::getCallerClass when there is no caller frame. This captures the alternatives considered. [1] describes the JDK use cases of getCallerClass and concludes that the user needs the ability to differentiate if there is no caller frame. The alternatives considered for getCallerClass to return when it’s called by the last frame on the stack (i.e. main() or from a JNI invoked method). 1. Optional.empty 2. null 3. StackWalker.NoCaller.class 4. last frame 5. Thread.class 6. throw an exception - not supported getCallerClass is intended for frameworks to find the caller on behalf. For 1-4, the caller-sensitive API will have to handle this corner case explicitly.     Class<?> caller = walker.getCallerClass(); // #1 it will do Optional.orElse or something     if (caller is present) {           // common path           :     } else {           // need to decide what to do     } #1 and #2 are a better option than #3 and #4 that it will get an exception if the user forgets to handle the no caller frame case. #5 returning Thread.class - the user can’t differentiate between no caller frame case vs Thread::run case. This API is intended for framework to use getting the caller and do the operation on behalf. It’s rare that such API is invoked from newly JNI attached thread. JDK caller-sensitive methods might be invoked via JNI attached thread and JDK is not going to use StackWalker::getCallerClass. The public static void main calling getCallerClass. #1, #2, #6 are the options to be chosen from. #1 incurs an extra object allocation but the common case always has a caller. #2 forces null check at every usage #6 the API expected to be invoked by JNI newly attached thread will have to call StackWalker::walk instead. IMO, #6 is the best approach such that the common cases are not impacted. If it's determined in the future that a need of a convenient method to find caller that may be absent, a new method could provide a new getCallerClassOrNull method in the future.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f671d5510375
          User: mchung
          Date: 2015-11-23 22:41:39 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f671d5510375 User: mchung Date: 2015-11-23 22:41:39 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/94838afd5e5b
          User: mchung
          Date: 2015-11-23 22:41:40 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/94838afd5e5b User: mchung Date: 2015-11-23 22:41:40 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f671d5510375
          User: lana
          Date: 2015-12-10 00:26:59 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f671d5510375 User: lana Date: 2015-12-10 00:26:59 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/94838afd5e5b
          User: lana
          Date: 2015-12-10 00:27:01 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/94838afd5e5b User: lana Date: 2015-12-10 00:27:01 +0000

            People

            • Assignee:
              mchung Mandy Chung
              Reporter:
              mchung Mandy Chung
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: