Probable bug within sun.management.StackTraceElementCompositeData
Mandy Chung
mandy.chung at oracle.com
Wed Oct 24 23:23:20 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181024/f36350e8/attachment-0001.html>
More information about the serviceability-dev
mailing list