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.ch...@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&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> > 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> 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
