Probable bug within sun.management.StackTraceElementCompositeData
Sven Reimers
sven.reimers at gmail.com
Thu Oct 25 16:32:41 UTC 2018
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.chung at 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.reimers at 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.chung at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181025/e749317c/attachment.html>
More information about the serviceability-dev
mailing list