8232592: <Unknown compiled code> is shown in jstack mixed mode

Hohensee, Paul hohensee at amazon.com
Tue Oct 22 20:29:36 UTC 2019


+1. Thanks, Chris and Yasumasa.

Paul

On 10/22/19, 1:02 PM, "serviceability-dev on behalf of Chris Plummer" <serviceability-dev-bounces at openjdk.java.net on behalf of chris.plummer at oracle.com> wrote:

    Hi Yasumasa,
    
    Looks good.
    
    thanks,
    
    Chris
    
    On 10/21/19 7:02 PM, Yasumasa Suenaga wrote:
    > Hi Chris,
    >
    > Thanks for your comment! I uploaded new webrev:
    >
    >   http://cr.openjdk.java.net/~ysuenaga/JDK-8232592/webrev.01/
    >
    >
    >> So what does it mean if it is an NMethod but is not native and names 
    >> != null. Should this ever happen? It seems odd that we don't print 
    >> out the frame type in this case, and also don't call printUnknown().
    >
    > I guess it might happen when call nmethod from JNI.
    > It would be handled as valid compiled code.
    >
    > ```
    >  166                       // print java frames, if any
    >  167                       if (names != null && names.length != 0) {
    >  168                          // print java frame(s)
    >  169                          for (int i = 0; i < names.length; i++) {
    >  170                              out.println(names[i]);
    >  171                          }
    >  172                       }
    >  ```
    >
    >
    > Thanks,
    >
    > Yasumasa
    >
    >
    > On 2019/10/22 2:25, Chris Plummer wrote:
    >> Hi Yasumasa,
    >>
    >> The call to getJavaNames() is not needed if the method is native. It 
    >> should be moved into the else block:
    >>
    >>                              if (cb.isNMethod()) {
    >>                                 if (cb.isNativeMethod()) {
    >> out.print(((CompiledMethod)cb).getMethod().externalNameAndSignature());
    >>                                    long diff = pc.minus(cb.codeBegin());
    >>                                    if (diff != 0L) {
    >>                                      out.print(" + 0x" + 
    >> Long.toHexString(diff));
    >>                                    }
    >>                                    out.println(" (Native method)");
    >>                                 } else {
    >>                                     names = getJavaNames(th, 
    >> f.localVariableBase());
    >>                                     if (names == null || names.length 
    >> == 0) {
    >>                                         // just print compiled code, 
    >> if can't determine method
    >> out.println("<Unknown compiled code>");
    >>                                     }
    >>                                 }
    >>                              } else if (cb.isBufferBlob()) {
    >>
    >> So what does it mean if it is an NMethod but is not native and names 
    >> != null. Should this ever happen? It seems odd that we don't print 
    >> out the frame type in this case, and also don't call printUnknown().
    >>
    >> thanks,
    >>
    >> Chris
    >>
    >> On 10/18/19 1:38 AM, Yasumasa Suenaga wrote:
    >>> Hi all,
    >>>
    >>> Please review this change.
    >>>
    >>>   JBS: https://bugs.openjdk.java.net/browse/JDK-8232592
    >>>   webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232592/webrev.00/
    >>>
    >>> I run `jhsdb jstack --mixed` to JShellToolProvider process, then I 
    >>> saw <Unknown compiled code>
    >>> in the stack as below:
    >>>
    >>> ```
    >>> "process reaper" #13 daemon prio=10 tid=0x00007f959c328000 
    >>> nid=0x1285 runnable [0x00007f9578025000]
    >>>    java.lang.Thread.State: RUNNABLE
    >>>    JavaThread state: _thread_in_native
    >>> 0x00007f95a27c5596 __waitpid + 0x56
    >>> 0x00007f958c601d79 <Unknown compiled code>
    >>> 0x00007f9585c5b4ac * java.lang.ProcessHandleImpl$1.run() bci:8 
    >>> line:138 (Compiled frame)
    >>> ```
    >>>
    >>> 0x7f958c601d79 is native method. jstack mixed mode should handle it.
    >>> This patch passed all tests on submit repo 
    >>> (mach5-one-ysuenaga-JDK-8232592-20191018-0600-6011163).
    >>>
    >>>
    >>> Thanks,
    >>>
    >>> Yasumasa
    >>
    
    



More information about the serviceability-dev mailing list