[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Probable bug within sun.management.StackTraceElementCompositeData
From:       Mandy Chung <mandy.chung () oracle ! com>
Date:       2018-10-25 16:36:58
Message-ID: 7ba5853b-91c7-23c1-4733-c0f868874b83 () oracle ! com
[Download RAW message or body]

Using JFR is a good idea.

Mandy

On 10/25/18 9:32 AM, Sven Reimers wrote:
> Hi Mandy,
> 
> I think I would like to get rid of this way of collecting profile data 
> for NetBeans IDE (all applications based on the NetBeans Platform). I 
> talked to Marcus Hirt and he suggested to use JFR from 11 onwards - I 
> think this is a very good idea and with this, the old code will just 
> be a fallback if JFR is not applicable.
> 
> What  do you think?
> 
> Sven
> 
> On Wed, Oct 24, 2018 at 4:22 PM Mandy Chung <mandy.chung@oracle.com 
> <mailto:mandy.chung@oracle.com>> wrote:
> 
> Hi Sven,
> 
> Do you have the performance numbers comparing the use of this
> internal API vs MBeanServer::invoke to convert ThreadInfo to
> CompositeData?
> 
> ThreadInfo is converted to an open data via MXBean support
> but not toCompositeData method NB is using.
> CompositeData is designed for interoperability between a
> JMX compliant client and a running JVM of different runtime
> version.   Hence it's intended to be converted through a mbean
> server.   I think we should first look into the performance
> of MBeanServer::invoke and it can be improved.
> 
> Mandy
> 
> 
> On 10/20/18 6:40 AM, Sven Reimers wrote:
> > Hi Mandy,
> > 
> > I think the main problem here is that there is no simple was to do
> > 
> > CompositeData data = ThreadInfo.toCompositeData(threadInfo)
> > 
> > using an   official API (there is only
> > ThreadInfo.from(CompositeData..).
> > 
> > Do you think it may be a good idea to add such a method? We are
> > using this approach due to performance reasons (details can be
> > found on the original NetBeans issue
> > <https://issues.apache.org/jira/browse/NETBEANS-1359?focusedCommentId=16657857&pag \
> > e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16657857>).
> >  
> > Thanks
> > 
> > Sven
> > 
> > On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers
> > <sven.reimers@gmail.com <mailto:sven.reimers@gmail.com>> wrote:
> > 
> > Hi Mandy,
> > 
> > Thanks for the pointer. I have not yet investigated the
> > usage, but will check if we can use the official API instead.
> > 
> > Thanks again for the quick response.
> > 
> > -Sven
> > 
> > Mandy Chung <mandy.chung@oracle.com
> > <mailto:mandy.chung@oracle.com>> schrieb am Mi., 17. Okt.
> > 2018, 19:50:
> > 
> > Hi Sven,
> > 
> > This NetBeans SamplesOutputStream calls
> > sun.management.ThreadInfoCompositeData.toCompositeData
> > which is an internal API.   It will be inaccessible when
> > strong encapsulation is enabled.
> > 
> > Have you looked into javax.management API to get the
> > CompositeData directly?
> > 
> > Mandy
> > 
> > On 10/15/18 10:51 AM, Mandy Chung wrote:
> > > Hi Sven,
> > > 
> > > It's indeed a bug in the order of names and values when
> > > constructing CompositeData for StackTraceElement.   I
> > > created https://bugs.openjdk.java.net/browse/JDK-8212197
> > > for this issue.
> > > 
> > > Mandy
> > > 
> > > On 10/14/18 3:52 PM, David Holmes wrote:
> > > > Hi Sven,
> > > > 
> > > > Moving to serviceability-dev mailing list. Please don't
> > > > reply to jdk-dev.
> > > > 
> > > > Thanks,
> > > > David
> > > > 
> > > > On 15/10/2018 5:42 AM, Sven Reimers wrote:
> > > > > Hi all,
> > > > > 
> > > > > I hope this is the correct e-mailing list. During out
> > > > > testing of Apache
> > > > > NetBeans 10 we discovered a problem with self sampling
> > > > > capability of
> > > > > NetBeans. Digging further into this problem
> > > > > (NETBEANS-1359
> > > > > <https://issues.apache.org/jira/browse/NETBEANS-1359>
> > > > > <https://issues.apache.org/jira/browse/NETBEANS-1359>)
> > > > > I debugged through
> > > > > the code and it seems that there is a problem with the
> > > > > order of the values
> > > > > and the order of the attributes.
> > > > > 
> > > > > From the code I see the order of the values is
> > > > > 
> > > > > final Object[] stackTraceElementItemValues = {
> > > > > ste.getClassLoaderName(),
> > > > > ste.getModuleName(),
> > > > > ste.getModuleVersion(),
> > > > > ste.getClassName(),
> > > > > ste.getMethodName(),
> > > > > ste.getFileName(),
> > > > > ste.getLineNumber(),
> > > > > ste.isNativeMethod(),
> > > > > };
> > > > > 
> > > > > compared to   the order of the attributes
> > > > > 
> > > > > 
> > > > > private static final String[] V5_ATTRIBUTES = {
> > > > > CLASS_NAME,
> > > > > METHOD_NAME,
> > > > > FILE_NAME,
> > > > > LINE_NUMBER,
> > > > > NATIVE_METHOD,
> > > > > };
> > > > > 
> > > > > private static final String[] V9_ATTRIBUTES = {
> > > > > CLASS_LOADER_NAME,
> > > > > MODULE_NAME,
> > > > > MODULE_VERSION,
> > > > > };
> > > > > 
> > > > > private static final String[]
> > > > > STACK_TRACE_ELEMENT_ATTRIBUTES =
> > > > > Stream.of(V5_ATTRIBUTES,
> > > > > V9_ATTRIBUTES).flatMap(Arrays::stream)
> > > > > .toArray(String[]::new);
> > > > > 
> > > > > which can be expanded to
> > > > > 
> > > > > CLASS_NAME,
> > > > > METHOD_NAME,
> > > > > FILE_NAME,
> > > > > LINE_NUMBER,
> > > > > NATIVE_METHOD,
> > > > > CLASS_LOADER_NAME,
> > > > > MODULE_NAME,
> > > > > MODULE_VERSION,
> > > > > 
> > > > > With the difference in ordering you will get an
> > > > > exception   in
> > > > > CompositeDataSupport, if you try to convert things
> > > > > (lines 228ff)
> > > > > 
> > > > > // Check each value, if not null, is of the
> > > > > open type defined for
> > > > > the
> > > > > // corresponding item
> > > > > for (String name : namesFromType) {
> > > > > Object value = items.get(name);
> > > > > if (value != null) {
> > > > > OpenType<?> itemType =
> > > > > compositeType.getType(name);
> > > > > if (!itemType.isValue(value)) {
> > > > > throw new OpenDataException(
> > > > > "Argument value of wrong
> > > > > type for item " + name
> > > > > +
> > > > > ": value " + value + ",
> > > > > type " + itemType);
> > > > > }
> > > > > }
> > > > > }
> > > > > 
> > > > > which is hard to compensate from the caller side.
> > > > > 
> > > > > I think the change, which introduced this was
> > > > > 
> > > > > https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470
> > > > >  
> > > > > 
> > > > > The proposed patch seems simple, just change the
> > > > > ordering of the attributes
> > > > > 
> > > > > private static final String[]
> > > > > STACK_TRACE_ELEMENT_ATTRIBUTES =
> > > > > Stream.of(V9_ATTRIBUTES,
> > > > > V5_ATTRIBUTES).flatMap(Arrays::stream)
> > > > > .toArray(String[]::new);
> > > > > 
> > > > > or change the value ordering to fit the attributes order.
> > > > > 
> > > > > Can anyone confirm the analysis?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > -Sven
> > > > > 
> > > 
> > 
> > 
> > 
> > -- 
> > Sven Reimers
> > 
> > * Senior Expert Software Architect
> > * Java Champion
> > * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> > * Community Leader   NetBeans: http://community.java.net/netbeans
> > Desktop Java:
> > http://community.java.net/javadesktop
> > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
> > * Duke's Choice Award Winner 2009
> > 
> > * XING: https://www.xing.com/profile/Sven_Reimers8
> > * LinkedIn: http://www.linkedin.com/in/svenreimers
> 
> 
> 
> -- 
> Sven Reimers
> 
> * Senior Expert Software Architect
> * Java Champion
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * Community Leader   NetBeans: http://community.java.net/netbeans
> Desktop Java: 
> http://community.java.net/javadesktop
> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
> * Duke's Choice Award Winner 2009
> 
> * XING: https://www.xing.com/profile/Sven_Reimers8
> * LinkedIn: http://www.linkedin.com/in/svenreimers


[Attachment #3 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>Using JFR is a good idea.<br>
      <br>
      Mandy<br>
    </tt><br>
    <div class="moz-cite-prefix">On 10/25/18 9:32 AM, Sven Reimers
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP+Jvx7=C9dRh1obSPaPWf3OdWij3+xXV-MnrsiAsncEQg8svw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div dir="ltr">Hi Mandy,
        <div><br>
        </div>
        <div>I think I would like to get rid of this way of collecting
          profile data for NetBeans IDE (all applications based on the
          NetBeans Platform). I talked to Marcus Hirt and he suggested
          to use JFR from 11 onwards - I think this is a very good idea
          and with this, the old code will just be a fallback if JFR is
          not applicable.</div>
        <div><br>
        </div>
        <div>What  do you think?</div>
        <div><br>
        </div>
        <div>Sven</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Wed, Oct 24, 2018 at 4:22 PM Mandy Chung &lt;<a
            href="mailto:mandy.chung@oracle.com" \
moz-do-not-send="true">mandy.chung@oracle.com</a>&gt;  wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000"> <tt>Hi Sven,<br>
              <br>
              Do you have the performance numbers comparing the use of
              this<br>
              internal API vs MBeanServer::invoke to convert ThreadInfo
              to<br>
              CompositeData?<br>
              <br>
              ThreadInfo is converted to an open data via MXBean support<br>
              but not toCompositeData method NB is using.   <br>
            </tt><tt><tt>CompositeData is designed for interoperability
                between a <br>
                JMX compliant client and a running JVM of different
                runtime<br>
                version.   Hence it's intended to be converted through a
                mbean<br>
                server.</tt></tt><tt><tt><tt>   I think we should first
                  look into the performance <br>
                  of MBeanServer::invoke and it can be improved.<br>
                </tt><br>
              </tt></tt><tt>Mandy<br>
              <br>
            </tt><br>
            <div class="m_-2529436922260425779moz-cite-prefix">On
              10/20/18 6:40 AM, Sven Reimers wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">
                <div dir="ltr">Hi Mandy,
                  <div><br>
                  </div>
                  <div>I think the main problem here is that there is no
                    simple was to do  </div>
                  <div><br>
                  </div>
                  <div>CompositeData data =
                    ThreadInfo.toCompositeData(threadInfo)</div>
                  <div><br>
                  </div>
                  <div>using an   official API (there is only
                    ThreadInfo.from(CompositeData..).</div>
                  <div><br>
                  </div>
                  <div>Do you think it may be a good idea to add such a
                    method? We are using this approach due to
                    performance reasons (details can be found on the
                    original  <a
href="https://issues.apache.org/jira/browse/NETBEANS-1359?focusedCommentId=16657857&am \
p;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16657857"
  target="_blank" moz-do-not-send="true">NetBeans
                      issue</a>).</div>
                  <div><br>
                  </div>
                  <div>Thanks</div>
                  <div><br>
                  </div>
                  <div>Sven</div>
                </div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr">On Wed, Oct 17, 2018 at 11:48 AM Sven
                  Reimers &lt;<a href="mailto:sven.reimers@gmail.com"
                    target="_blank" \
moz-do-not-send="true">sven.reimers@gmail.com</a>&gt;  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div dir="auto">Hi Mandy,
                    <div dir="auto"><br>
                    </div>
                    <div dir="auto">Thanks for the pointer. I have not
                      yet investigated the usage, but will check if we
                      can use the official API instead.</div>
                    <div dir="auto"><br>
                    </div>
                    <div dir="auto">Thanks again for the quick response.</div>
                    <div dir="auto"><br>
                    </div>
                    <div dir="auto">-Sven</div>
                  </div>
                  <br>
                  <div class="gmail_quote">
                    <div dir="ltr">Mandy Chung &lt;<a
                        href="mailto:mandy.chung@oracle.com"
                        target="_blank" \
moz-do-not-send="true">mandy.chung@oracle.com</a>&gt;  schrieb am Mi., 17. Okt. 2018, \
19:50:<br>  </div>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div text="#000000" bgcolor="#FFFFFF"> <tt>Hi
                          Sven,<br>
                          <br>
                          This NetBeans SamplesOutputStream calls
                          sun.management.ThreadInfoCompositeData.toCompositeData<br>
                          which is an internal API.   It will be
                          inaccessible when<br>
                          strong encapsulation is enabled.<br>
                          <br>
                          Have you looked into javax.management API to
                          get the<br>
                          CompositeData directly?<br>
                          <br>
                          Mandy<br>
                        </tt><br>
                        <div
class="m_-2529436922260425779m_4778674824494396935m_-3423247025102408496moz-cite-prefix">On
  10/15/18 10:51 AM, Mandy Chung wrote:<br>
                        </div>
                        <blockquote type="cite"> Hi Sven,<br>
                          <br>
                          It's indeed a bug in the order of names and
                          values when constructing CompositeData for
                          StackTraceElement.   I created <a
class="m_-2529436922260425779m_4778674824494396935m_-3423247025102408496moz-txt-link-freetext"
 href="https://bugs.openjdk.java.net/browse/JDK-8212197" rel="noreferrer"
                            target="_blank" \
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8212197</a>  for this \
issue.<br>  <br>
                          Mandy<br>
                          <br>
                          <div
class="m_-2529436922260425779m_4778674824494396935m_-3423247025102408496moz-cite-prefix">On
  10/14/18 3:52 PM, David Holmes wrote:<br>
                          </div>
                          <blockquote type="cite">Hi Sven, <br>
                            <br>
                            Moving to serviceability-dev mailing list.
                            Please don't reply to jdk-dev. <br>
                            <br>
                            Thanks, <br>
                            David <br>
                            <br>
                            On 15/10/2018 5:42 AM, Sven Reimers wrote: <br>
                            <blockquote type="cite">Hi all, <br>
                              <br>
                              I hope this is the correct e-mailing list.
                              During out testing of Apache <br>
                              NetBeans 10 we discovered a problem with
                              self sampling capability of <br>
                              NetBeans. Digging further into this
                              problem (NETBEANS-1359 <br>
                              <a
class="m_-2529436922260425779m_4778674824494396935m_-3423247025102408496moz-txt-link-rfc2396E"
 href="https://issues.apache.org/jira/browse/NETBEANS-1359"
                                rel="noreferrer" target="_blank"
                                \
moz-do-not-send="true">&lt;https://issues.apache.org/jira/browse/NETBEANS-1359&gt;</a>)
  I debugged through <br>
                              the code and it seems that there is a
                              problem with the order of the values <br>
                              and the order of the attributes. <br>
                              <br>
                                From the code I see the order of the
                              values is <br>
                              <br>
                                               final Object[]
                              stackTraceElementItemValues = { <br>
                                                       ste.getClassLoaderName(), <br>
                                                       ste.getModuleName(), <br>
                                                       ste.getModuleVersion(), <br>
                                                       ste.getClassName(), <br>
                                                       ste.getMethodName(), <br>
                                                       ste.getFileName(), <br>
                                                       ste.getLineNumber(), <br>
                                                       ste.isNativeMethod(), <br>
                                               }; <br>
                              <br>
                              compared to   the order of the attributes <br>
                              <br>
                              <br>
                                       private static final String[]
                              V5_ATTRIBUTES = { <br>
                                               CLASS_NAME, <br>
                                               METHOD_NAME, <br>
                                               FILE_NAME, <br>
                                               LINE_NUMBER, <br>
                                               NATIVE_METHOD, <br>
                                       }; <br>
                              <br>
                                       private static final String[]
                              V9_ATTRIBUTES = { <br>
                                               CLASS_LOADER_NAME, <br>
                                               MODULE_NAME, <br>
                                               MODULE_VERSION, <br>
                                       }; <br>
                              <br>
                                       private static final String[]
                              STACK_TRACE_ELEMENT_ATTRIBUTES = <br>
                                               Stream.of(V5_ATTRIBUTES,
                              V9_ATTRIBUTES).flatMap(Arrays::stream) <br>
                                                           .toArray(String[]::new); \
<br>  <br>
                              which can be expanded to <br>
                              <br>
                                               CLASS_NAME, <br>
                                               METHOD_NAME, <br>
                                               FILE_NAME, <br>
                                               LINE_NUMBER, <br>
                                               NATIVE_METHOD, <br>
                                               CLASS_LOADER_NAME, <br>
                                               MODULE_NAME, <br>
                                               MODULE_VERSION, <br>
                              <br>
                              With the difference in ordering you will
                              get an exception   in <br>
                              CompositeDataSupport, if you try to
                              convert things (lines 228ff) <br>
                              <br>
                                               // Check each value, if not null,
                              is of the open type defined for <br>
                              the <br>
                                               // corresponding item <br>
                                               for (String name : namesFromType)
                              { <br>
                                                       Object value =
                              items.get(name); <br>
                                                       if (value != null) { <br>
                                                               OpenType&lt;?&gt;
                              itemType = compositeType.getType(name); <br>
                                                               if
                              (!itemType.isValue(value)) { <br>
                                                                       throw new
                              OpenDataException( <br>
                                                                                      \
"Argument  value of wrong type for item " + name <br>
                              + <br>
                                                                                      \
": value " +  value + ", type " + itemType); <br>
                                                               } <br>
                                                       } <br>
                                               } <br>
                              <br>
                              which is hard to compensate from the
                              caller side. <br>
                              <br>
                              I think the change, which introduced this
                              was <br>
                              <br>
                              <a
class="m_-2529436922260425779m_4778674824494396935m_-3423247025102408496moz-txt-link-freetext"
 href="https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470"
  rel="noreferrer" target="_blank"
                                \
moz-do-not-send="true">https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470</a>
  <br>
                              <br>
                              The proposed patch seems simple, just
                              change the ordering of the attributes <br>
                              <br>
                                   private static final String[]
                              STACK_TRACE_ELEMENT_ATTRIBUTES = <br>
                                               Stream.of(V9_ATTRIBUTES,
                              V5_ATTRIBUTES).flatMap(Arrays::stream) <br>
                                                           .toArray(String[]::new); \
<br>  <br>
                              or change the value ordering to fit the
                              attributes order. <br>
                              <br>
                              Can anyone confirm the analysis? <br>
                              <br>
                              Thanks <br>
                              <br>
                              -Sven <br>
                              <br>
                            </blockquote>
                          </blockquote>
                          <br>
                        </blockquote>
                        <br>
                      </div>
                    </blockquote>
                  </div>
                </blockquote>
              </div>
              <br clear="all">
              <div><br>
              </div>
              -- <br>
              <div dir="ltr"
                class="m_-2529436922260425779gmail_signature"
                data-smartmail="gmail_signature">
                <div dir="ltr">
                  <div>
                    <div dir="ltr">
                      <div dir="ltr">
                        <div>Sven Reimers<br>
                          <br>
                          * Senior Expert Software Architect</div>
                        <div>* Java Champion<br>
                          * NetBeans Dream Team Member: <a
                            href="http://dreamteam.netbeans.org"
                            target="_blank" \
                moz-do-not-send="true">http://dreamteam.netbeans.org</a><br>
                          * Community Leader   NetBeans: <a
                            href="http://community.java.net/netbeans"
                            target="_blank" \
                moz-do-not-send="true">http://community.java.net/netbeans</a><br>
                                                                       Desktop Java: \
<a  href="http://community.java.net/javadesktop"
                            target="_blank" \
moz-do-not-send="true">http://community.java.net/javadesktop</a><br>  </div>
                        * JUG Leader JUG Bodensee: <a
                          href="http://www.jug-bodensee.de"
                          target="_blank" \
moz-do-not-send="true">http://www.jug-bodensee.de</a><br>  <div>* Duke's Choice Award \
Winner 2009<br>  <br>
                          * XING: <a
                            href="https://www.xing.com/profile/Sven_Reimers8"
                            target="_blank" \
                moz-do-not-send="true">https://www.xing.com/profile/Sven_Reimers8</a><br>
                
                          * LinkedIn: <a
                            href="http://www.linkedin.com/in/svenreimers"
                            target="_blank" \
moz-do-not-send="true">http://www.linkedin.com/in/svenreimers</a><br>  </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br clear="all">
      <div><br>
      </div>
      -- <br>
      <div dir="ltr" class="gmail_signature"
        data-smartmail="gmail_signature">
        <div dir="ltr">
          <div>
            <div dir="ltr">
              <div dir="ltr">
                <div>Sven Reimers<br>
                  <br>
                  * Senior Expert Software Architect</div>
                <div>* Java Champion<br>
                  * NetBeans Dream Team Member: <a
                    href="http://dreamteam.netbeans.org" target="_blank"
                    moz-do-not-send="true">http://dreamteam.netbeans.org</a><br>
                  * Community Leader   NetBeans: <a
                    href="http://community.java.net/netbeans"
                    target="_blank" \
                moz-do-not-send="true">http://community.java.net/netbeans</a><br>
                                                               Desktop Java: <a
                    href="http://community.java.net/javadesktop"
                    target="_blank" \
moz-do-not-send="true">http://community.java.net/javadesktop</a><br>  </div>
                * JUG Leader JUG Bodensee: <a
                  href="http://www.jug-bodensee.de" target="_blank"
                  moz-do-not-send="true">http://www.jug-bodensee.de</a><br>
                <div>* Duke's Choice Award Winner 2009<br>
                  <br>
                  * XING: <a
                    href="https://www.xing.com/profile/Sven_Reimers8"
                    target="_blank" \
                moz-do-not-send="true">https://www.xing.com/profile/Sven_Reimers8</a><br>
                
                  * LinkedIn: <a
                    href="http://www.linkedin.com/in/svenreimers"
                    target="_blank" \
moz-do-not-send="true">http://www.linkedin.com/in/svenreimers</a><br>  </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic