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

> Still not a review, or is it now? I'd say still not a review as I'm only looking at the general structure. Cheers, David On 14/05/2020 1:37 am, Reingruber, Richard wrote: Hi David, On 4/05/2020 8:33 pm, Reingruber, Richard wrote: // Trimmed the list of recipients. If the list gets too lon

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, It looks good in general. But I agree with David, the TIMED_WAITING thread state can be escaped by timeout. More sophisticated logic is require to track it precisely. I'd suggest to get rid of the TIMED_WAITING in this condition as it is never passed to the assertThreadState() as an

Re: RFR(S): JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Hi Alex, The fix looks good. Thanks, Serguei On 5/13/20 19:20, Alex Menkov wrote: Hi all, please review tiny (and I suppose trivial) fix for https://bugs.openjdk.java.net/browse/JDK-8244973 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket_merge/webrev/ This bug i

Re: RFR(S): JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

On 14/05/2020 12:38 pm, Alex Menkov wrote: Hi David, On 05/13/2020 19:27, David Holmes wrote: Hi Alex, On 14/05/2020 12:20 pm, Alex Menkov wrote: Hi all, please review tiny (and I suppose trivial) fix for https://bugs.openjdk.java.net/browse/JDK-8244973 webrev: http://cr.openjdk.java.net/~am

Re: RFR(S): JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Hi David, On 05/13/2020 19:27, David Holmes wrote: Hi Alex, On 14/05/2020 12:20 pm, Alex Menkov wrote: Hi all, please review tiny (and I suppose trivial) fix for https://bugs.openjdk.java.net/browse/JDK-8244973 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket_merge/w

Re: RFR(S): JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Hi Alex, On 14/05/2020 12:20 pm, Alex Menkov wrote: Hi all, please review tiny (and I suppose trivial) fix for https://bugs.openjdk.java.net/browse/JDK-8244973 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket_merge/webrev/ This bug is a result of bad merge: base:

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, On 14/05/2020 10:55 am, Alex Menkov wrote: Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8229829 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev/ The fix adds handling for WAITING That part is good. (and for consistency TIMED_WAIT

RFR(S): JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Hi all, please review tiny (and I suppose trivial) fix for https://bugs.openjdk.java.net/browse/JDK-8244973 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket_merge/webrev/ This bug is a result of bad merge: base: out.stderrShouldBeEmpty(); fix for JDK-8242009: -

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

Looks good to me. On Wed, May 13, 2020 at 5:55 PM Alex Menkov wrote: > > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8229829 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev/ > > The fix adds handling for WAITING (and for consistency

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 all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8229829 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/Locks_waiting/webrev/ The fix adds handling for WAITING (and for consistency TIMED_WAITING which is not used in the test) states as it has for BLOCKED state. --

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

Hi Richard, 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. I'm thinking it would be more safe to run full tier5. I can do it after you get all thumbs ups. Thanks, Serguei On 4/24/20 01:18, Reingruber, Rich

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

On 05/12/2020 13:40, serguei.spit...@oracle.com wrote: Hi Alex, This seems to resolve most of the Alan's concerns. Though, I'm not sure if we can treat users that deploy and use agents as developers. I think users that deploy agent or use tools to load agents can be called administrators

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

Hi David, > On 4/05/2020 8:33 pm, Reingruber, Richard wrote: > > // Trimmed the list of recipients. If the list gets too long then the > > message needs to be approved > > // by a moderator. > Yes I noticed that too :) In general if you send to hotspot-dev you > shouldn't need to also send to h

Re: RFR 8244105: JDK 11.0.7 -Xlog gc issue with file path if not exist

Thanks David. I closed the issue as 'will not fix'. Harold On 5/13/2020 12:13 AM, David Holmes wrote: Hi Harold, On 12/05/2020 10:49 pm, Harold Seigel wrote: Hi David, Thanks for looking at this. This change disables logging and issuing a warning for any errors in the -Xlog arguments that