Discussion:
Probable bug within sun.management.StackTraceElementCompositeData
David Holmes
2018-10-14 22:52:07 UTC
Permalink
Hi Sven,

Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.

Thanks,
David
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>) 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
Mandy Chung
2018-10-15 17:51:10 UTC
Permalink
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
Post by David Holmes
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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>) 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
2018-10-17 06:16:27 UTC
Permalink
Hi,

thanks for fixing. What about a backport to 11?

Thanks

-Sven
Post by David Holmes
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
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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
Mandy Chung
2018-10-17 16:26:22 UTC
Permalink
I plan to request the backport to 11u.

Mandy
Post by Sven Reimers
Hi,
thanks for fixing. What about a backport to 11?
Thanks
-Sven
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
Post by David Holmes
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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
Mandy Chung
2018-10-17 17:50:28 UTC
Permalink
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
Post by David Holmes
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
Post by David Holmes
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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>) 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
2018-10-17 18:48:07 UTC
Permalink
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
Post by David Holmes
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
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
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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
2018-10-20 13:40:07 UTC
Permalink
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
Post by Sven Reimers
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
Post by David Holmes
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
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
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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
Mandy Chung
2018-10-24 23:23:20 UTC
Permalink
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
Post by Sven Reimers
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
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
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
Post by David Holmes
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
Post by David Holmes
Hi Sven,
Moving to serviceability-dev mailing list. Please don't
reply to jdk-dev.
Thanks,
David
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
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
2018-10-25 16:32:41 UTC
Permalink
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
Post by David Holmes
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
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
Post by Sven Reimers
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
Post by David Holmes
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
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
Hi Sven,
Moving to serviceability-dev mailing list. Please don't reply to jdk-dev.
Thanks,
David
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
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
Mandy Chung
2018-10-25 16:36:58 UTC
Permalink
Using JFR is a good idea.

Mandy
Post by Sven Reimers
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
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
Post by Sven Reimers
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
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
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
Post by David Holmes
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
Post by David Holmes
Hi Sven,
Moving to serviceability-dev mailing list. Please don't
reply to jdk-dev.
Thanks,
David
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
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
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
Loading...