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&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16657857>).

Thanks

Sven

On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers <sven.reim...@gmail.com <mailto:sven.reim...@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.ch...@oracle.com
    <mailto:mandy.ch...@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

Reply via email to