Probable bug within sun.management.StackTraceElementCompositeData
Mandy Chung
mandy.chung at oracle.com
Thu Oct 25 16:36:58 UTC 2018
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?
>
> Sven
>
> On Wed, Oct 24, 2018 at 4:22 PM Mandy Chung <mandy.chung at oracle.com
> <mailto: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 <mailto: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
>> <mailto: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/fd2c7019/attachment-0001.html>
More information about the serviceability-dev
mailing list