Re: RFR: JDK-8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING

+1 Thanks, David On 15/05/2020 6:18 am, serguei.spit...@oracle.com wrote: Hi Alex, LGTM. Thanks, Serguei On 5/14/20 11:04, Alex Menkov wrote: I agree with the point. updated webrev (only WAITING handling is added): http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev.2/ --alex

Re: RFR: 8241080: Consolidate signature parsing code in serviceability tools

Hi Daniil, Thank you for the update! It looks good to me. > Regarding CR for the JDWP spec issues I guess, you wanted to say "CSR", not CR. :) Thanks, Serguei On 5/14/20 13:33, Daniil Titov wrote: Hi Serguei and Chris, Please review a new version of the change [1] that addresses your

Re: RFR: 8241080: Consolidate signature parsing code in serviceability tools

Hi Serguei and Chris, Please review a new version of the change [1] that addresses your comments. Testing: Mach5 tier1-tier5 tests successfully passed. Regarding CR for the JDWP spec issues related to missing type information in some of the protocol packet descriptions [3], as Chris has just

Re: RFR: JDK-8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING

Hi Alex, LGTM. Thanks, Serguei On 5/14/20 11:04, Alex Menkov wrote: I agree with the point. updated webrev (only WAITING handling is added): http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev.2/ --alex On 05/13/2020 19:20, David Holmes wrote: Hi Alex, On 14/05/2020 10:55 am,

Re: Ping: RFR: JDK-8243012: Fix issues in j.l.i package info

Hi Alex, LGTM. Thanks, Serguei On 5/14/20 11:30, Alex Menkov wrote: Hi Alan, Serguei, updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/java_instrument_spec/webrev.3/ --alex On 05/14/2020 04:25, Alan Bateman wrote: On 12/05/2020 20:57, Alex Menkov wrote: Hi Alan, Serguei, lets

Re: Ping: RFR: JDK-8243012: Fix issues in j.l.i package info

On 14/05/2020 19:30, Alex Menkov wrote: Hi Alan, Serguei, updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/java_instrument_spec/webrev.3/ Thanks. -Alan

Re: Ping: RFR: JDK-8243012: Fix issues in j.l.i package info

Hi Alan, Serguei, updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/java_instrument_spec/webrev.3/ --alex On 05/14/2020 04:25, Alan Bateman wrote: On 12/05/2020 20:57, Alex Menkov wrote: Hi Alan, Serguei, lets try one more time :) What about: Agents can transform classes in

Re: RFR: JDK-8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING

I agree with the point. updated webrev (only WAITING handling is added): http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev.2/ --alex On 05/13/2020 19:20, David Holmes wrote: Hi Alex, On 14/05/2020 10:55 am, Alex Menkov wrote: Hi all, Please review the fix for

RFR(XS): 8222005: ClassRedefinition crashes with: guarantee(false) failed: OLD and/or OBSOLETE method(s) found

Please, review a fix for The Kitchensink bug:   https://bugs.openjdk.java.net/browse/JDK-8222005 Webrev:   http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-redef.1/ Summary:   The VM_RedefineClasses::doit() uses two helper classes

Re: Ping: RFR: JDK-8243012: Fix issues in j.l.i package info

On 12/05/2020 20:57, Alex Menkov wrote: Hi Alan, Serguei, lets try one more time :) What about: Agents can transform classes in arbitrary ways at load time, transform modules, or transform the bytecode of methods of already loaded classes. Developers or administrators that deploy agents,

RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Hi Serguei, > Thank you for the bug report update - it is helpful. > The fix/update looks good in general but I need more time to check some > points. Sure. I'd be happy if you could look at it again. > I'm thinking it would be more safe to run full tier5. > I can do it after you get all

RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Ok. Thanks for the feedback anyways. Cheers, Richard. -Original Message- From: David Holmes Sent: Donnerstag, 14. Mai 2020 07:29 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net;