(13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed

Please, review the test bug fix for:   https://bugs.openjdk.java.net/browse/JDK-8224555 Webrev:   http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8224555-mon-events2-test.1/ Summary:   The test sleeps for 1 sec in hope to get a

Re: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

Thanks for looking into this. Chris On 6/20/19 6:42 PM, Daniil Titov wrote: Thank you, Chris and Serguei, for reviewing this change. I did more testing with a test program on Linux that repeats get_namespace_pid() method and reads from the real file ( the copy of /proc//status). I paused the

Re: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

Thank you, Chris and Serguei, for reviewing this change. I did more testing with a test program on Linux that repeats get_namespace_pid() method and reads from the real file ( the copy of /proc//status). I paused the program after the first several lines ( but not "NSpid:" line) where

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

On 6/20/19 17:36, Daniel D. Daugherty wrote: On 6/20/19 7:59 PM, serguei.spit...@oracle.com wrote: Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

On 6/20/19 7:59 PM, serguei.spit...@oracle.com wrote: Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also exception message ("Thread-" + i + " was

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Thanks! Serguei On 6/20/19 17:22, Alex Menkov wrote: LGTM --alex On 06/20/2019 16:59, serguei.spit...@oracle.com wrote: Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

LGTM --alex On 06/20/2019 16:59, serguei.spit...@oracle.com wrote: Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also exception message ("Thread-" +

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Hi Alex, Thank you a lot for review! On 6/20/19 16:30, Alex Menkov wrote: Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also exception message ("Thread-" + i + " was interrupted by timeout!") is not correct): in tc04t001

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Hi Dan, On 6/20/19 16:17, Daniel D. Daugherty wrote: On 6/19/19 9:59 PM, serguei.spit...@oracle.com wrote: Sorry, forgot the  bug title to add to the email subject. Thanks, Serguei

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Hi Serguei, Main idea looks good. I'd simplify threads[i].join/threads[i].done logic with CountDownLatch (note also exception message ("Thread-" + i + " was interrupted by timeout!") is not correct): in tc04t001 class add final static CountDownLatch threadsDoneSignal = new

Re: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Thanks a lot, Chris! Serguei On 6/20/19 16:04, Chris Plummer wrote: Looks good. Chris On 6/20/19 2:56 PM, serguei.spit...@oracle.com wrote: PING ... On 6/19/19 18:59, serguei.spit...@oracle.com wrote: Sorry, forgot the  bug title to add to the email subject. Thanks, Serguei On 6/19/19

Re: RFR (S): 8223736:jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

On 6/19/19 9:59 PM, serguei.spit...@oracle.com wrote: Sorry, forgot the  bug title to add to the email subject. Thanks, Serguei On 6/19/19 6:09 PM, serguei.spit...@oracle.com wrote: Please review a fix for test bug:   https://bugs.openjdk.java.net/browse/JDK-8223736 Webrev:

Re: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

Looks good. Chris On 6/20/19 2:56 PM, serguei.spit...@oracle.com wrote: PING ... On 6/19/19 18:59, serguei.spit...@oracle.com wrote: Sorry, forgot the  bug title to add to the email subject. Thanks, Serguei On 6/19/19 6:09 PM, serguei.spit...@oracle.com wrote: Please review a fix for

Re: RFR (S): 8223736: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events

PING ... On 6/19/19 18:59, serguei.spit...@oracle.com wrote: Sorry, forgot the  bug title to add to the email subject. Thanks, Serguei On 6/19/19 6:09 PM, serguei.spit...@oracle.com wrote: Please review a fix for test bug:   https://bugs.openjdk.java.net/browse/JDK-8223736 Webrev:

Re: Slow class loading when running JVM in debug mode

With respect to the specific issue brought up in https://youtrack.jetbrains.com/issue/JBR-1611: "If we look into the code, we'll see that whenever a new class is loaded and an event about it is delivered, when a garbage collection has occurred,

Re: A Bug about the JVM Attach mechanism

Sorry it took me a while to understand the specifics of the problem. :) David On 20/06/2019 3:37 am, nijiaben wrote: Yes Alan, I mean this -- Original -- *From: * "Alan Bateman"; *Date: * Thu, Jun 20, 2019 02:54 PM *To: * "nijiaben"; "David Holmes";

Re: Slow class loading when running JVM in debug mode

Hi Egor, yes, I‘d say this is something well known. The reason for this is that a debugging agent will request some JVMTI capabilities like "can_access_local_variables" which can only be requested at JVM startup. However, once these capabilities have been taken, certain kinds of optimizations

Re: RFR: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

Hi Daniil, It looks good to me. Thanks, Serguei On 6/19/19 21:02, Daniil Titov wrote: Please review the change that fixes an intermittent failure of serviceability/dcmd/framework/* tests on Linux platform. The problem here is that get_namespace_pid() method, that is called by

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

On 20/06/2019 15:49, Egor Ushakov wrote: Hi David, any news on https://bugs.openjdk.java.net/browse/JDK-8212117? I do not see any activity on this :( cc'ing Brent as he has picked up this issue. I think we want to fix this and David has a patch in one of the linked issues. As it's changing

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

Hi David, any news on https://bugs.openjdk.java.net/browse/JDK-8212117? I do not see any activity on this :( Thanks, Egor On 09-Apr-19 15:53, David Holmes wrote: On 9/04/2019 7:36 pm, Egor Ushakov wrote: Hi David, you're right! The fix for JDK-8212117 should help here as well. After that

Re: OperatingSystemMXBean unaware of container memory limits

Hi Andrew, I am aware of the limitations of the OperatingSystemMXBean and was hoping to address these limitations during the implementation of https://bugs.openjdk.java.net/browse/JDK-8199944 . It would be helpful if you feel this is important

OperatingSystemMXBean unaware of container memory limits

Hi all, Apologies if this is not the most appropriate list, in which case please direct me where to go. I've noticed a surprising result from the com.sun.management.OperatingSystemMXBean implementation when running in a containerized (specifically, using Docker on Linux) environment. The bean

Re: A Bug about the JVM Attach mechanism

Yes Alan, I mean this -- Original -- From: "Alan Bateman"; Date: Thu, Jun 20, 2019 02:54 PM To: "nijiaben"; "David Holmes"; "serviceability-dev"; "jdk8u-dev"; "hotspot-runtime-dev"; Subject: Re: A Bug about the JVM Attach mechanism On 20/06/2019

RE: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

Ok, then jdk/jdk is fine for me. In case this turns out to be more important, I guess it could be backported to an update release. > -Original Message- > From: gary.ad...@oracle.com > Sent: Donnerstag, 20. Juni 2019 11:56 > To: Langer, Christoph > Cc: OpenJDK Serviceability ; >

Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

During testing the failure was only observed in a questionable test on linux-x64-debug builds. I question whether P3 was a correct assessment when the bug was filed. The only reason this encounter caused a problem with the double close is the test was looping and getting the same file descriptor

Slow class loading when running JVM in debug mode

Hi everyone! we have detected that a process started with the debug agent (even when debugger is not actually attached) may run significantly slower than without the agent, see: https://youtrack.jetbrains.com/issue/JBR-1611 We all thought that without the debugger attached there should not be

Re: A Bug about the JVM Attach mechanism

I think it is https://bugs.openjdk.java.net/browse/JDK-8225193 The jcmd failed to attach if /tmp/.java_pid* is removed. It doesn't find file which is used as listener socket and send signal to start attach listener. (It suppose that listener

Re: A Bug about the JVM Attach mechanism

(Speaking on behalf of my own experience) Yes Alan, you're right on. I'm fairly sure that's the symptom that Nijiaben is asking about here. - Kris On Wed, Jun 19, 2019 at 11:54 PM Alan Bateman wrote: > On 20/06/2019 05:10, nijiaben wrote: > > : > > I know this mechanism, can we provide means

Re: A Bug about the JVM Attach mechanism

On 20/06/2019 05:10, nijiaben wrote: : I know this mechanism, can we provide means of recovery to avoid unavailability caused by accidental deletion? Are you concerned about tmpreaper or cron jobs that periodically cleanup /tmp? There may indeed be an issue for applications that run for weeks