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
