ThreadInfoCompositeData.compositeType() broken in 11 and later

Hi, seems with the change for 8198253: ThreadInfo.from(CompositeData) incorrectly accepts CompositeData with missing JDK 6 attributes ThreadInfoCompositeData.compositeType() was broken. It just returns public static CompositeType compositeType() { return ThreadInfoCompositeTypes.co

Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions

Hi Paul, On 20/10/2018 2:05 AM, Hohensee, Paul wrote: If we put the flag into deprecation, I’d like to keep it for a year so people have time to change their monitoring code (one release to change their code, and another to run with their new code), which would be two releases. I don’t know ho

Re: ThreadInfoCompositeData.compositeType() broken in 11 and later

Probable fix use Runtime.version().feature() instead of 0: public static CompositeType compositeType() { return ThreadInfoCompositeTypes.compositeTypes.get(Runtime.version().feature()); } Sven On Sun, Oct 21, 2018 at 10:50 AM Sven Reimers wrote: > Hi, > > seems with the change

OpenDataException thrown when constructing CompositeData for ThreadInfo

Hi, one more problem to go After applying the proposed fix for the ThreadINfoCompositeData.compositeTyoe() the following exception is raised: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.re

RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent

Re-sending to the correct mailing lists. Please disregard the other email. http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ https://bugs.openjdk.java.net/browse/JDK-8212200 Hi, CDS has various built-in assumptions that classes loaded by SystemDictionary::reso

Re: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent

Hi Ioi, Generally seems okay. On 22/10/2018 11:15 AM, Ioi Lam wrote: Re-sending to the correct mailing lists. Please disregard the other email. http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ https://bugs.openjdk.java.net/browse/JDK-8212200 Hi, CDS has

Re: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file

Gentle reminder! Thanks, - Jini On 10/9/2018 11:31 AM, Jini George wrote: Hello! [Including runtime-dev since the changes are in runtime code] Requesting reviews for: Webrev: http://cr.openjdk.java.net/~jgeorge/8200613/webrev.01/ BugID: https://bugs.openjdk.java.net/browse/JDK-8200613 Issue

Re: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file

Hi Jini, Did you see my earlier reply? I might have sent it out during the mail server outage days :-( http://openjdk.5641.n7.nabble.com/RFR-S-JDK-8200613-SA-jstack-throws-UnmappedAddressException-with-a-CDS-core-file-td352681.html#a353026 Here was my reply again: Hi Jini, The changes look

Re: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent

Hi David, Thanks for the review. Updated webrev: http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ More comments below: On 10/21/18 6:57 PM, David Holmes wrote: Hi I

Re: OpenDataException thrown when constructing CompositeData for ThreadInfo

Hi Sven, Do you have a sample ThreadInfo to reproduce this issue?   That will be helpful.  JMX monitoring is not impacted as far as I can tell. NB profiling is using this internal API `sun.management.ThreadInfoCompositeData::toCompositeData` which may be unused since JMX supports MXBean. Ma