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? SvenOn Wed, Oct 24, 2018 at 4:22 PM Mandy Chung <mandy.ch...@oracle.com <mailto: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 <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-- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeansDesktop 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
