From jaroslav.bachorik at oracle.com Thu Jan 9 06:05:11 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 09 Jan 2014 15:05:11 +0100 Subject: jmx-dev RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' Message-ID: <52CEAC97.6040707@oracle.com> Please, review this small test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. Thanks, -JB- From shanliang.jiang at oracle.com Thu Jan 9 06:27:29 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 09 Jan 2014 15:27:29 +0100 Subject: jmx-dev RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <52CEB1D1.7000101@oracle.com> The fix looks OK. Line 232 is not necessary. The simplest fix might be only to add the following lines to 94 if (getPlatform() == null) { return; } Shanliang Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit > gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From chris.hegarty at oracle.com Thu Jan 9 09:02:57 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 9 Jan 2014 17:02:57 +0000 Subject: jmx-dev RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <379B3BE4-031B-4885-B16F-5DF4DA0484D0@oracle.com> Looks fine to me. -Chris. On 9 Jan 2014, at 14:05, Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From staffan.larsen at oracle.com Thu Jan 9 23:15:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 10 Jan 2014 08:15:50 +0100 Subject: jmx-dev RFR 8031420: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails on some platforms: Unable to locate 'libjvm.so' In-Reply-To: <52CEAC97.6040707@oracle.com> References: <52CEAC97.6040707@oracle.com> Message-ID: <6A08D74B-6227-40D8-805A-83F46FE33CE5@oracle.com> Looks good! Thanks, /Staffan On 9 jan 2014, at 15:05, Jaroslav Bachorik wrote: > Please, review this small test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031420 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031420/webrev.00 > > The test needs to check for the supported platform first and exit gracefully if it is run on an unsupported one. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Tue Jan 14 03:27:32 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 12:27:32 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52B03858.7040409@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> Message-ID: <52D51F24.7000904@oracle.com> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? Thanks! -JB- On 17.12.2013 12:41, Jaroslav Bachorik wrote: > Anyone? > > -JB- > > On 15.11.2013 15:25, Jaroslav Bachorik wrote: >> Please, review this test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >> >> The test was facing intermittent failures due to not 100% failproof >> interprocess synchronization using lock files. The solution is rewriting >> the shell test to pure Java and use stdout/stderr processing for the >> application started by the test to assess its status. >> >> A part of the change is also few improvements to the >> jdk.testlibrary.ProcessTools. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Tue Jan 14 04:13:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Jan 2014 13:13:07 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52D51F24.7000904@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> Message-ID: JMXStartStopTest.java:162 I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. Other than that I think it looks good. /Staffan On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: > Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? > > Thanks! > > -JB- > > On 17.12.2013 12:41, Jaroslav Bachorik wrote: >> Anyone? >> >> -JB- >> >> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>> Please, review this test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>> >>> The test was facing intermittent failures due to not 100% failproof >>> interprocess synchronization using lock files. The solution is rewriting >>> the shell test to pure Java and use stdout/stderr processing for the >>> application started by the test to assess its status. >>> >>> A part of the change is also few improvements to the >>> jdk.testlibrary.ProcessTools. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Tue Jan 14 05:13:40 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 14 Jan 2014 14:13:40 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> Message-ID: <52D53804.8000505@oracle.com> Thanks, Staffan! On 14.1.2014 13:13, Staffan Larsen wrote: > JMXStartStopTest.java:162 > I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. Also, there are some minor changes in the webrev due to merging. Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 Cheers, -JB- > > Other than that I think it looks good. > > /Staffan > > On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: > >> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >> >> Thanks! >> >> -JB- >> >> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>> Anyone? >>> >>> -JB- >>> >>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>> Please, review this test fix. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>> >>>> The test was facing intermittent failures due to not 100% failproof >>>> interprocess synchronization using lock files. The solution is rewriting >>>> the shell test to pure Java and use stdout/stderr processing for the >>>> application started by the test to assess its status. >>>> >>>> A part of the change is also few improvements to the >>>> jdk.testlibrary.ProcessTools. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From Alan.Bateman at oracle.com Tue Jan 14 05:26:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 13:26:33 +0000 Subject: jmx-dev Dropping support for the IIOP transport from the RMI connector Message-ID: <52D53B09.1020604@oracle.com> In JDK 8 we updated the JMX Remote API and the RMI connector so that support for the IIOP transport is optional. RI and Oracle JDK builds continue to support it, builds of Compact Profiles leave it out (as CORBA and a number of its dependencies are not defined for any subset Profile of Java SE). I would like to bring up the topic of dropping support for the IIOP transport completely, that is change the RMI connector so that it only supports the default JRMP transport. From what I can tell then this isn't used very widely and I'm curious if anyone would really notice or care. The rational for doing this is the same reason that we downgraded it to optional, it's problematic for our modularity efforts due to the CORBA Tie classes in javax.management.remote.rmi. So is anyone using it in a way that would be highly disruptive if it were removed in JDK 9? -Alan. From jaroslav.bachorik at oracle.com Mon Jan 20 07:41:39 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 20 Jan 2014 16:41:39 +0100 Subject: jmx-dev RFR 8031559: javax/management/monitor/StartStopTest.java fails intermittently Message-ID: <52DD43B3.9010707@oracle.com> Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8031559 Webrev: http://cr.openjdk.java.net/~jbachorik/8031559/webrev.00 The test fails intermittently - the "called" flag it is using to indicate that a workload was successfully processed is not volatile or synchronized and is set from a different thread than the one which checks it. This can lead to race conditions making the test fail. The other test improvement is to honor the "test.timeout.factor" property to properly scale any timeouts used in the test. Thanks, -JB- From daniel.fuchs at oracle.com Mon Jan 20 08:12:56 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 20 Jan 2014 17:12:56 +0100 Subject: jmx-dev RFR 8031559: javax/management/monitor/StartStopTest.java fails intermittently In-Reply-To: <52DD43B3.9010707@oracle.com> References: <52DD43B3.9010707@oracle.com> Message-ID: <52DD4B08.5070408@oracle.com> Hi Jaroslav, Looks good. If the test fails again you might consider using a CountDownLatch - or something like that - instead of a simple volatile boolean. It would allow you to use in the loop and remove the first doSleep() at line 154. I'm afraid I don't have anything better than sleep for the second call at line 166 anyway. Let's keep what you have now and see if it completely solve the issue. -- daniel On 1/20/14 4:41 PM, Jaroslav Bachorik wrote: > Please, review the following test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031559 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031559/webrev.00 > > The test fails intermittently - the "called" flag it is using to > indicate that a workload was successfully processed is not volatile or > synchronized and is set from a different thread than the one which > checks it. This can lead to race conditions making the test fail. The > other test improvement is to honor the "test.timeout.factor" property to > properly scale any timeouts used in the test. > > Thanks, > > -JB- From staffan.larsen at oracle.com Mon Jan 20 23:48:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 08:48:40 +0100 Subject: jmx-dev RFR 8031559: javax/management/monitor/StartStopTest.java fails intermittently In-Reply-To: <52DD43B3.9010707@oracle.com> References: <52DD43B3.9010707@oracle.com> Message-ID: You added: 30 * @library /lib/testlibrary 31 * @run build jdk.testlibrary.Utils ... 57 import jdk.testlibrary.Utils; But I don?t see any actual usage of Utils. Otherwise it looks good. /Staffan On 20 jan 2014, at 16:41, Jaroslav Bachorik wrote: > Please, review the following test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8031559 > Webrev: http://cr.openjdk.java.net/~jbachorik/8031559/webrev.00 > > The test fails intermittently - the "called" flag it is using to indicate that a workload was successfully processed is not volatile or synchronized and is set from a different thread than the one which checks it. This can lead to race conditions making the test fail. The other test improvement is to honor the "test.timeout.factor" property to properly scale any timeouts used in the test. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Jan 20 23:52:27 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 08:52:27 +0100 Subject: jmx-dev RFR 8031559: javax/management/monitor/StartStopTest.java fails intermittently In-Reply-To: References: <52DD43B3.9010707@oracle.com> Message-ID: <52DE273B.4020307@oracle.com> On 21.1.2014 08:48, Staffan Larsen wrote: > You added: > > 30 * @library /lib/testlibrary > 31 * @run build jdk.testlibrary.Utils > ... > 57 import jdk.testlibrary.Utils; > > But I don?t see any actual usage of Utils. Correct. I have updated the Utils to give easy access to the timeout factor but the patch hasn't been approved yet :( I will remove the Utils reference before pushing. -JB- > > Otherwise it looks good. > > /Staffan > > On 20 jan 2014, at 16:41, Jaroslav Bachorik wrote: > >> Please, review the following test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8031559 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8031559/webrev.00 >> >> The test fails intermittently - the "called" flag it is using to indicate that a workload was successfully processed is not volatile or synchronized and is set from a different thread than the one which checks it. This can lead to race conditions making the test fail. The other test improvement is to honor the "test.timeout.factor" property to properly scale any timeouts used in the test. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Mon Jan 20 23:59:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 08:59:57 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <52D53804.8000505@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> <52D53804.8000505@oracle.com> Message-ID: <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> Looks good! And very sorry for letting this slip. Thanks, /Staffan On 14 jan 2014, at 14:13, Jaroslav Bachorik wrote: > Thanks, Staffan! > > On 14.1.2014 13:13, Staffan Larsen wrote: >> JMXStartStopTest.java:162 >> I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. > > I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. > > Also, there are some minor changes in the webrev due to merging. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 > > Cheers, > > -JB- > >> >> Other than that I think it looks good. >> >> /Staffan >> >> On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: >> >>> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >>> >>> Thanks! >>> >>> -JB- >>> >>> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>>> Anyone? >>>> >>>> -JB- >>>> >>>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>>> Please, review this test fix. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>>> >>>>> The test was facing intermittent failures due to not 100% failproof >>>>> interprocess synchronization using lock files. The solution is rewriting >>>>> the shell test to pure Java and use stdout/stderr processing for the >>>>> application started by the test to assess its status. >>>>> >>>>> A part of the change is also few improvements to the >>>>> jdk.testlibrary.ProcessTools. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From staffan.larsen at oracle.com Tue Jan 21 00:00:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 21 Jan 2014 09:00:46 +0100 Subject: jmx-dev RFR 8031559: javax/management/monitor/StartStopTest.java fails intermittently In-Reply-To: <52DE273B.4020307@oracle.com> References: <52DD43B3.9010707@oracle.com> <52DE273B.4020307@oracle.com> Message-ID: On 21 jan 2014, at 08:52, Jaroslav Bachorik wrote: > On 21.1.2014 08:48, Staffan Larsen wrote: >> You added: >> >> 30 * @library /lib/testlibrary >> 31 * @run build jdk.testlibrary.Utils >> ... >> 57 import jdk.testlibrary.Utils; >> >> But I don?t see any actual usage of Utils. > > Correct. I have updated the Utils to give easy access to the timeout factor but the patch hasn't been approved yet :( My fault. I forgot that review - done now. > I will remove the Utils reference before pushing. Or you can use the new Utils now :-) /Staffan > > -JB- > >> >> Otherwise it looks good. >> >> /Staffan >> >> On 20 jan 2014, at 16:41, Jaroslav Bachorik wrote: >> >>> Please, review the following test change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8031559 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8031559/webrev.00 >>> >>> The test fails intermittently - the "called" flag it is using to indicate that a workload was successfully processed is not volatile or synchronized and is set from a different thread than the one which checks it. This can lead to race conditions making the test fail. The other test improvement is to honor the "test.timeout.factor" property to properly scale any timeouts used in the test. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Tue Jan 21 00:01:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 09:01:34 +0100 Subject: jmx-dev [ping] Re: RFR 8022221: Intermittent test failures in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> References: <52862EDC.4080703@oracle.com> <52B03858.7040409@oracle.com> <52D51F24.7000904@oracle.com> <52D53804.8000505@oracle.com> <98D2338B-FD62-4B16-BA94-5D1A01D4BFCA@oracle.com> Message-ID: <52DE295E.7070400@oracle.com> On 21.1.2014 08:59, Staffan Larsen wrote: > Looks good! And very sorry for letting this slip. Thanks Staffan. NP! I guess I can leave the Utils in the patch for 8031559 :) -JB- > > Thanks, > /Staffan > > On 14 jan 2014, at 14:13, Jaroslav Bachorik wrote: > >> Thanks, Staffan! >> >> On 14.1.2014 13:13, Staffan Larsen wrote: >>> JMXStartStopTest.java:162 >>> I see no path that calls testConnect with port == -1, so can we we remove the setting of port to 4567? I don?t like that hardcoded port, and I don?t see it being used. >> >> I've removed the port setting magic - now the testConnect(...) needs to be called with the requested port number. >> >> Also, there are some minor changes in the webrev due to merging. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.01 >> >> Cheers, >> >> -JB- >> >>> >>> Other than that I think it looks good. >>> >>> /Staffan >>> >>> On 14 jan 2014, at 12:27, Jaroslav Bachorik wrote: >>> >>>> Ok, trying again. Could anyone, please, spare some time to review this test stabilization fix? >>>> >>>> Thanks! >>>> >>>> -JB- >>>> >>>> On 17.12.2013 12:41, Jaroslav Bachorik wrote: >>>>> Anyone? >>>>> >>>>> -JB- >>>>> >>>>> On 15.11.2013 15:25, Jaroslav Bachorik wrote: >>>>>> Please, review this test fix. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8022221 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8022221/webrev.00 >>>>>> >>>>>> The test was facing intermittent failures due to not 100% failproof >>>>>> interprocess synchronization using lock files. The solution is rewriting >>>>>> the shell test to pure Java and use stdout/stderr processing for the >>>>>> application started by the test to assess its status. >>>>>> >>>>>> A part of the change is also few improvements to the >>>>>> jdk.testlibrary.ProcessTools. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Tue Jan 21 05:14:16 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 21 Jan 2014 14:14:16 +0100 Subject: jmx-dev RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52B3FEBE.40106@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> Message-ID: <52DE72A8.9050807@oracle.com> Based on the experience while fixing https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the patch not to require an exact number for the blocked count - it will pass whenever the reported blocked count is at least large as the the expected number. Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 Thanks, -JB- On 20.12.2013 09:24, Jaroslav Bachorik wrote: > On 20.12.2013 03:27, David Holmes wrote: >> Sorry for the delay - still catching up after vacation (only 435 openjdk >> emails left :( ). > > NP > >> >> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>> On 19.11.2013 19:55, David Holmes wrote: >>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>> Hi David, >>>>> >>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> I think your phaser usage is incorrect: >>>>>> >>>>>> 88 public void run() { >>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>> 90 synchronized(lock1) { >>>>>> 91 System.out.println("[LockerThread obtained >>>>>> Lock1]"); >>>>>> 92 p.arrive(); // phase[2] >>>>>> 93 } >>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>> 95 } >>>>>> >>>>>> Here the current thread can release itself at line 94. You have >>>>>> assumed >>>>>> that the phase[2] arrive will be a trigger to release the main thread >>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>> statement >>>>>> yet, so the current thread arrives then does arrive-and-wait but the >>>>>> number of arrivals is 2 so it doesn't wait. >>>>>> >>>>>> A CyclicBarrier per phase may be clearer. >>>>> >>>>> Yes, thanks for pointing this out. But, wouldn't >>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've tried to >>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>> expected >>>>> it pollutes code with the necessity to catch various exceptions >>>>> (InterruptedException, BarrierException etc.). So, if the simple fix >>>>> with Phaser would do the trick I would better use that. >>>> >>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know if >>>> other tests have the same issue - the concern would be ensuring there's >>>> no possibility of deadlocks in general. >>> >>> I've updated the webrev with the one using p.arriveAndAwaitAdvance() at >>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>> >>> Are you ok with this change then? >> >> I think you have the same problem anywhere that arrive() is used eg: >> >> 129 p.arrive(); // phase[2] >> 130 p.arriveAndAwaitAdvance(); // phase[3] >> >> and >> >> 185 p.arrive(); // phase[2] >> 186 } >> 187 p.arriveAndAwaitAdvance(); // phase[3] > > Very probable :( Also, when analysing the recurrence of JDK-8029890 I've > found out that Phaser.arriveAndAwaitAdvance() actually blocked the > thread in a way that it increased the number of contentions reported :( > CyclicBarrier seems to wait instead - I will have to use CyclicBarrier > when testing the number of reported contentions and Phaser when testing > the number of reported waits :/ > > -JB- > >> >> David >> ------ >> >>> Thanks, >>> >>> -JB- >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>> Hi, >>>>>>> >>>>>>> after discussing this with Mandy I've rewritten the test to use the >>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>> easier to >>>>>>> follow the test logic. >>>>>>> >>>>>>> The waited time, the blocked time and the waited counts are only >>>>>>> checked >>>>>>> for sanity (increasing values) since it is not possible to do the >>>>>>> reliable checks against hard numbers. >>>>>>> >>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and -Xint >>>>>>> and >>>>>>> the test seems to pass constantly. >>>>>>> >>>>>>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>> updated >>>>>>>> implementation in JDK6. >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>> >>>>>>>> The test fails due to the change in mustang where >>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>> Thread.sleep() >>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the test for >>>>>>>> synchronization purposes and this breaks the test. >>>>>>>> >>>>>>>> In the patch I propose to replace Thread.sleep() with busy wait and >>>>>>>> hinting the scheduler by Thread.yield(). While not very elegant it >>>>>>>> successfully works around inclusion of unknown number of >>>>>>>> Thread.sleep()s >>>>>>>> (they are called in loop). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>> >>>>> >>> > From david.holmes at oracle.com Tue Jan 21 22:25:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2014 16:25:47 +1000 Subject: jmx-dev RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DE72A8.9050807@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> Message-ID: <52DF646B.3000606@oracle.com> Hi Jaroslav, I still see some suspect uses of p.arrive() instead of p.arriveAndAwaitAdvance(). David On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: > Based on the experience while fixing > https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the patch > not to require an exact number for the blocked count - it will pass > whenever the reported blocked count is at least large as the the > expected number. > > Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 > > Thanks, > > -JB- > > On 20.12.2013 09:24, Jaroslav Bachorik wrote: >> On 20.12.2013 03:27, David Holmes wrote: >>> Sorry for the delay - still catching up after vacation (only 435 openjdk >>> emails left :( ). >> >> NP >> >>> >>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>> On 19.11.2013 19:55, David Holmes wrote: >>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>> Hi David, >>>>>> >>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> I think your phaser usage is incorrect: >>>>>>> >>>>>>> 88 public void run() { >>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>> 90 synchronized(lock1) { >>>>>>> 91 System.out.println("[LockerThread obtained >>>>>>> Lock1]"); >>>>>>> 92 p.arrive(); // phase[2] >>>>>>> 93 } >>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>> 95 } >>>>>>> >>>>>>> Here the current thread can release itself at line 94. You have >>>>>>> assumed >>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>> thread >>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>> statement >>>>>>> yet, so the current thread arrives then does arrive-and-wait but the >>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>> >>>>>>> A CyclicBarrier per phase may be clearer. >>>>>> >>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>> tried to >>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>> expected >>>>>> it pollutes code with the necessity to catch various exceptions >>>>>> (InterruptedException, BarrierException etc.). So, if the simple fix >>>>>> with Phaser would do the trick I would better use that. >>>>> >>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know if >>>>> other tests have the same issue - the concern would be ensuring >>>>> there's >>>>> no possibility of deadlocks in general. >>>> >>>> I've updated the webrev with the one using p.arriveAndAwaitAdvance() at >>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>> >>>> Are you ok with this change then? >>> >>> I think you have the same problem anywhere that arrive() is used eg: >>> >>> 129 p.arrive(); // phase[2] >>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>> >>> and >>> >>> 185 p.arrive(); // phase[2] >>> 186 } >>> 187 p.arriveAndAwaitAdvance(); // phase[3] >> >> Very probable :( Also, when analysing the recurrence of JDK-8029890 I've >> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >> thread in a way that it increased the number of contentions reported :( >> CyclicBarrier seems to wait instead - I will have to use CyclicBarrier >> when testing the number of reported contentions and Phaser when testing >> the number of reported waits :/ >> >> -JB- >> >>> >>> David >>> ------ >>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> after discussing this with Mandy I've rewritten the test to use the >>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>> easier to >>>>>>>> follow the test logic. >>>>>>>> >>>>>>>> The waited time, the blocked time and the waited counts are only >>>>>>>> checked >>>>>>>> for sanity (increasing values) since it is not possible to do the >>>>>>>> reliable checks against hard numbers. >>>>>>>> >>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>> -Xint >>>>>>>> and >>>>>>>> the test seems to pass constantly. >>>>>>>> >>>>>>>> New webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>> updated >>>>>>>>> implementation in JDK6. >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>> >>>>>>>>> The test fails due to the change in mustang where >>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>> Thread.sleep() >>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the test for >>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>> >>>>>>>>> In the patch I propose to replace Thread.sleep() with busy wait >>>>>>>>> and >>>>>>>>> hinting the scheduler by Thread.yield(). While not very elegant it >>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>> Thread.sleep()s >>>>>>>>> (they are called in loop). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>> >>>>>> >>>> >> > From jaroslav.bachorik at oracle.com Wed Jan 22 00:12:06 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 09:12:06 +0100 Subject: jmx-dev RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DF646B.3000606@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> Message-ID: Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go through the patch to see if there are any other omissions. Thanks, -JB- David Holmes wrote: >Hi Jaroslav, > >I still see some suspect uses of p.arrive() instead of >p.arriveAndAwaitAdvance(). > >David > >On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >> Based on the experience while fixing >> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >patch >> not to require an exact number for the blocked count - it will pass >> whenever the reported blocked count is at least large as the the >> expected number. >> >> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >> >> Thanks, >> >> -JB- >> >> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>> On 20.12.2013 03:27, David Holmes wrote: >>>> Sorry for the delay - still catching up after vacation (only 435 >openjdk >>>> emails left :( ). >>> >>> NP >>> >>>> >>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> I think your phaser usage is incorrect: >>>>>>>> >>>>>>>> 88 public void run() { >>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>> 90 synchronized(lock1) { >>>>>>>> 91 System.out.println("[LockerThread >obtained >>>>>>>> Lock1]"); >>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>> 93 } >>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>> 95 } >>>>>>>> >>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>> assumed >>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>> thread >>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>> statement >>>>>>>> yet, so the current thread arrives then does arrive-and-wait >but the >>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>> >>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>> >>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>> tried to >>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>> expected >>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >fix >>>>>>> with Phaser would do the trick I would better use that. >>>>>> >>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >if >>>>>> other tests have the same issue - the concern would be ensuring >>>>>> there's >>>>>> no possibility of deadlocks in general. >>>>> >>>>> I've updated the webrev with the one using >p.arriveAndAwaitAdvance() at >>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>> >>>>> Are you ok with this change then? >>>> >>>> I think you have the same problem anywhere that arrive() is used >eg: >>>> >>>> 129 p.arrive(); // phase[2] >>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>> >>>> and >>>> >>>> 185 p.arrive(); // phase[2] >>>> 186 } >>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>> >>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >I've >>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>> thread in a way that it increased the number of contentions reported >:( >>> CyclicBarrier seems to wait instead - I will have to use >CyclicBarrier >>> when testing the number of reported contentions and Phaser when >testing >>> the number of reported waits :/ >>> >>> -JB- >>> >>>> >>>> David >>>> ------ >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> after discussing this with Mandy I've rewritten the test to >use the >>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>> easier to >>>>>>>>> follow the test logic. >>>>>>>>> >>>>>>>>> The waited time, the blocked time and the waited counts are >only >>>>>>>>> checked >>>>>>>>> for sanity (increasing values) since it is not possible to do >the >>>>>>>>> reliable checks against hard numbers. >>>>>>>>> >>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>> -Xint >>>>>>>>> and >>>>>>>>> the test seems to pass constantly. >>>>>>>>> >>>>>>>>> New webrev: >http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>> updated >>>>>>>>>> implementation in JDK6. >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>> Webrev: >http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>> >>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>> Thread.sleep() >>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >test for >>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>> >>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >wait >>>>>>>>>> and >>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >elegant it >>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>> Thread.sleep()s >>>>>>>>>> (they are called in loop). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>> >>>>>>> >>>>> >>> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20140122/4bf68bbd/attachment.html From jaroslav.bachorik at oracle.com Wed Jan 22 05:07:30 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 22 Jan 2014 14:07:30 +0100 Subject: jmx-dev RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> Message-ID: <52DFC292.8040401@oracle.com> Updated webrev with no "arrive()" calls dangling. - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07 -JB- On 22.1.2014 09:12, Jaroslav Bachorik wrote: > Argh. Sorry. Probably messed up when restoring my crashed HDD. I will go through the patch to see if there are any other omissions. > > Thanks, > -JB- > > David Holmes wrote: >> Hi Jaroslav, >> >> I still see some suspect uses of p.arrive() instead of >> p.arriveAndAwaitAdvance(). >> >> David >> >> On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >>> Based on the experience while fixing >>> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >> patch >>> not to require an exact number for the blocked count - it will pass >>> whenever the reported blocked count is at least large as the the >>> expected number. >>> >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >>> >>> Thanks, >>> >>> -JB- >>> >>> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>>> On 20.12.2013 03:27, David Holmes wrote: >>>>> Sorry for the delay - still catching up after vacation (only 435 >> openjdk >>>>> emails left :( ). >>>> >>>> NP >>>> >>>>> >>>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> I think your phaser usage is incorrect: >>>>>>>>> >>>>>>>>> 88 public void run() { >>>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>>> 90 synchronized(lock1) { >>>>>>>>> 91 System.out.println("[LockerThread >> obtained >>>>>>>>> Lock1]"); >>>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>>> 93 } >>>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>>> 95 } >>>>>>>>> >>>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>>> assumed >>>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>>> thread >>>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>>> statement >>>>>>>>> yet, so the current thread arrives then does arrive-and-wait >> but the >>>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>>> >>>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>>> >>>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>>> tried to >>>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>>> expected >>>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >> fix >>>>>>>> with Phaser would do the trick I would better use that. >>>>>>> >>>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >> if >>>>>>> other tests have the same issue - the concern would be ensuring >>>>>>> there's >>>>>>> no possibility of deadlocks in general. >>>>>> >>>>>> I've updated the webrev with the one using >> p.arriveAndAwaitAdvance() at >>>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>>> >>>>>> Are you ok with this change then? >>>>> >>>>> I think you have the same problem anywhere that arrive() is used >> eg: >>>>> >>>>> 129 p.arrive(); // phase[2] >>>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>>> >>>>> and >>>>> >>>>> 185 p.arrive(); // phase[2] >>>>> 186 } >>>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>>> >>>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >> I've >>>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>>> thread in a way that it increased the number of contentions reported >> :( >>>> CyclicBarrier seems to wait instead - I will have to use >> CyclicBarrier >>>> when testing the number of reported contentions and Phaser when >> testing >>>> the number of reported waits :/ >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> ------ >>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> after discussing this with Mandy I've rewritten the test to >> use the >>>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>>> easier to >>>>>>>>>> follow the test logic. >>>>>>>>>> >>>>>>>>>> The waited time, the blocked time and the waited counts are >> only >>>>>>>>>> checked >>>>>>>>>> for sanity (increasing values) since it is not possible to do >> the >>>>>>>>>> reliable checks against hard numbers. >>>>>>>>>> >>>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>>> -Xint >>>>>>>>>> and >>>>>>>>>> the test seems to pass constantly. >>>>>>>>>> >>>>>>>>>> New webrev: >> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>>> updated >>>>>>>>>>> implementation in JDK6. >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>>> Webrev: >> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>>> Thread.sleep() >>>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >> test for >>>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>>> >>>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >> wait >>>>>>>>>>> and >>>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >> elegant it >>>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>>> Thread.sleep()s >>>>>>>>>>> (they are called in loop). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From david.holmes at oracle.com Wed Jan 22 22:06:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jan 2014 16:06:04 +1000 Subject: jmx-dev RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52DFC292.8040401@oracle.com> References: <52651646.4050705@oracle.com> <5289E4F5.1080807@oracle.com> <528A8084.5060406@oracle.com> <528B7906.7010708@oracle.com> <528BB41A.4070107@oracle.com> <52A5AD7B.1060403@oracle.com> <52B3AB16.30206@oracle.com> <52B3FEBE.40106@oracle.com> <52DE72A8.9050807@oracle.com> <52DF646B.3000606@oracle.com> <52DFC292.8040401@oracle.com> Message-ID: <52E0B14C.2020105@oracle.com> On 22/01/2014 11:07 PM, Jaroslav Bachorik wrote: > Updated webrev with no "arrive()" calls dangling. > > - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.07 Thanks looks okay. The proof as always is in the running of the test. David > -JB- > > On 22.1.2014 09:12, Jaroslav Bachorik wrote: >> Argh. Sorry. Probably messed up when restoring my crashed HDD. I will >> go through the patch to see if there are any other omissions. >> >> Thanks, >> -JB- >> >> David Holmes wrote: >>> Hi Jaroslav, >>> >>> I still see some suspect uses of p.arrive() instead of >>> p.arriveAndAwaitAdvance(). >>> >>> David >>> >>> On 21/01/2014 11:14 PM, Jaroslav Bachorik wrote: >>>> Based on the experience while fixing >>>> https://bugs.openjdk.java.net/browse/JDK-8032377 I've updated the >>> patch >>>> not to require an exact number for the blocked count - it will pass >>>> whenever the reported blocked count is at least large as the the >>>> expected number. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.06 >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>> On 20.12.2013 09:24, Jaroslav Bachorik wrote: >>>>> On 20.12.2013 03:27, David Holmes wrote: >>>>>> Sorry for the delay - still catching up after vacation (only 435 >>> openjdk >>>>>> emails left :( ). >>>>> >>>>> NP >>>>> >>>>>> >>>>>> On 9/12/2013 9:46 PM, Jaroslav Bachorik wrote: >>>>>>> On 19.11.2013 19:55, David Holmes wrote: >>>>>>>> On 20/11/2013 12:43 AM, Jaroslav Bachorik wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 18.11.2013 22:03, David Holmes wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> I think your phaser usage is incorrect: >>>>>>>>>> >>>>>>>>>> 88 public void run() { >>>>>>>>>> 89 p.arriveAndAwaitAdvance(); // phase[1] >>>>>>>>>> 90 synchronized(lock1) { >>>>>>>>>> 91 System.out.println("[LockerThread >>> obtained >>>>>>>>>> Lock1]"); >>>>>>>>>> 92 p.arrive(); // phase[2] >>>>>>>>>> 93 } >>>>>>>>>> 94 p.arriveAndAwaitAdvance(); // phase[3] >>>>>>>>>> 95 } >>>>>>>>>> >>>>>>>>>> Here the current thread can release itself at line 94. You have >>>>>>>>>> assumed >>>>>>>>>> that the phase[2] arrive will be a trigger to release the main >>>>>>>>>> thread >>>>>>>>>> but it may not have reached its arriveAndAwaitAdvance phase[2] >>>>>>>>>> statement >>>>>>>>>> yet, so the current thread arrives then does arrive-and-wait >>> but the >>>>>>>>>> number of arrivals is 2 so it doesn't wait. >>>>>>>>>> >>>>>>>>>> A CyclicBarrier per phase may be clearer. >>>>>>>>> >>>>>>>>> Yes, thanks for pointing this out. But, wouldn't >>>>>>>>> p.arriveAndAwaitAdvance() instead of p.arrive() suffice? I've >>>>>>>>> tried to >>>>>>>>> replace Phaser with CyclicBarrier but while it seems to work as >>>>>>>>> expected >>>>>>>>> it pollutes code with the necessity to catch various exceptions >>>>>>>>> (InterruptedException, BarrierException etc.). So, if the simple >>> fix >>>>>>>>> with Phaser would do the trick I would better use that. >>>>>>>> >>>>>>>> In this case yes arriveAndAwaitAdvance would fix it. I don't know >>> if >>>>>>>> other tests have the same issue - the concern would be ensuring >>>>>>>> there's >>>>>>>> no possibility of deadlocks in general. >>>>>>> >>>>>>> I've updated the webrev with the one using >>> p.arriveAndAwaitAdvance() at >>>>>>> line 92 - http://cr.openjdk.java.net/~jbachorik/6309226/webrev.04 >>>>>>> >>>>>>> Are you ok with this change then? >>>>>> >>>>>> I think you have the same problem anywhere that arrive() is used >>> eg: >>>>>> >>>>>> 129 p.arrive(); // phase[2] >>>>>> 130 p.arriveAndAwaitAdvance(); // phase[3] >>>>>> >>>>>> and >>>>>> >>>>>> 185 p.arrive(); // phase[2] >>>>>> 186 } >>>>>> 187 p.arriveAndAwaitAdvance(); // phase[3] >>>>> >>>>> Very probable :( Also, when analysing the recurrence of JDK-8029890 >>> I've >>>>> found out that Phaser.arriveAndAwaitAdvance() actually blocked the >>>>> thread in a way that it increased the number of contentions reported >>> :( >>>>> CyclicBarrier seems to wait instead - I will have to use >>> CyclicBarrier >>>>> when testing the number of reported contentions and Phaser when >>> testing >>>>> the number of reported waits :/ >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> ------ >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 18/11/2013 7:59 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> after discussing this with Mandy I've rewritten the test to >>> use the >>>>>>>>>>> j.u.concurrent for synchronization - this also makes it much >>>>>>>>>>> easier to >>>>>>>>>>> follow the test logic. >>>>>>>>>>> >>>>>>>>>>> The waited time, the blocked time and the waited counts are >>> only >>>>>>>>>>> checked >>>>>>>>>>> for sanity (increasing values) since it is not possible to do >>> the >>>>>>>>>>> reliable checks against hard numbers. >>>>>>>>>>> >>>>>>>>>>> I ran the test in a tight loop for 1500 times using -Xcomp and >>>>>>>>>>> -Xint >>>>>>>>>>> and >>>>>>>>>>> the test seems to pass constantly. >>>>>>>>>>> >>>>>>>>>>> New webrev: >>> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.03 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 21.10.2013 13:55, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review this small patch for a test failing due to the >>>>>>>>>>>> updated >>>>>>>>>>>> implementation in JDK6. >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>>>>>>>>>> Webrev: >>> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The test fails due to the change in mustang where >>>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>>>>>>>>>> ThreadMXBean.getThreadInfo().getWaitedCount() include >>>>>>>>>>>> Thread.sleep() >>>>>>>>>>>> too. Unfortunately, Thread.sleep() is used throughout the >>> test for >>>>>>>>>>>> synchronization purposes and this breaks the test. >>>>>>>>>>>> >>>>>>>>>>>> In the patch I propose to replace Thread.sleep() with busy >>> wait >>>>>>>>>>>> and >>>>>>>>>>>> hinting the scheduler by Thread.yield(). While not very >>> elegant it >>>>>>>>>>>> successfully works around inclusion of unknown number of >>>>>>>>>>>> Thread.sleep()s >>>>>>>>>>>> (they are called in loop). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From rob.mckenna at oracle.com Mon Jan 27 16:50:23 2014 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 28 Jan 2014 00:50:23 +0000 Subject: jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced In-Reply-To: <52E6C4D2.3060703@gmail.com> References: <52E6C4D2.3060703@gmail.com> Message-ID: <52E6FECF.7030408@oracle.com> Hi Maryan, I'm cc'ing the jmx-dev folks. (and bcc'ing the jdk7u-dev alias) Hopefully they'll help move this conversation forward. -Rob On 27/01/14 20:42, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote: > Hello > > As a reporter of JI-9009639 / JDK-8031753 > bug I'd like to > inform you about the following. > > > Jaroslav Bachor?k > added > a comment -2014-01-22 04:32 > Not a regression. > > Oops. Sorry. Indeed I should have left this field blank. > I'd understood the meaning of 'Regression' field incorrectly and had > filled it in bug report by mistake. :( > > > Jaroslav Bachor?k > added > a comment -2014-01-22 04:32 > If you insist on this issue being a regression, please, provide the > exact version where the behavior was as expected. > > As I see all branches have this code for ages... > > [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c > ./src/share/classes/javax/management/remote/JMXServiceURL.java | grep > 'local = InetAddress.getLocalHost();' > /home/marbug/cpp/jab/tmp/jdk6/jdk > ohair 9 2d585507a41b Fri Jan 30 16:27:33 2009 -0800 > src/share/classes/javax/management/remote/JMXServiceURL.java: local = > InetAddress.getLocalHost(); > [marbug at server1 jdk]$ pwd && hg annotate -r 0 -f -a -u -d -n -c > ./src/share/classes/javax/management/remote/JMXServiceURL.java | grep > 'local = InetAddress.getLocalHost();' > /home/marbug/cpp/jab/tmp/jdk6/jdk > duke 0 0c738a3e5791 Fri Jan 30 16:00:53 2009 -0800 > src/share/classes/javax/management/remote/JMXServiceURL.java: local = > InetAddress.getLocalHost(); > [marbug at server1 jdk]$ cd ../../jdk7u/jdk/ > [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c > ./src/share/classes/javax/management/remote/JMXServiceURL.java | grep > 'local = InetAddress.getLocalHost();' > /home/marbug/cpp/jab/tmp/jdk7u/jdk > duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000 > src/share/classes/javax/management/remote/JMXServiceURL.java: local = > InetAddress.getLocalHost(); > [marbug at server1 jdk]$ cd ../../jdk8/jdk/ > [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c > ./src/share/classes/javax/management/remote/JMXServiceURL.java | grep > 'local = InetAddress.getLocalHost();' > /home/marbug/cpp/jab/tmp/jdk8/jdk > duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000 > src/share/classes/javax/management/remote/JMXServiceURL.java: local = > InetAddress.getLocalHost(); > [marbug at server1 jdk]$ cd ../../jdk9/jdk/ > [marbug at server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c > ./src/share/classes/javax/management/remote/JMXServiceURL.java | grep > 'local = InetAddress.getLocalHost();' > /home/marbug/cpp/jab/tmp/jdk9/jdk > duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000 > src/share/classes/javax/management/remote/JMXServiceURL.java: local = > InetAddress.getLocalHost(); > > So the expected behaviour is just my conslusion/suggestion. > > > Jaroslav Bachor?k > added > a comment -2014-01-22 04:32 > I would argue that workaround should be L - it is easy to fix the > hostname and the solution is persistent. If the reporter can describe > a situation where fixing the hostname is not an option the workaround > should stay at M. > > As I understand you suggest to fix hostname and/or an appropriate > record in /etc/hosts (under Linux). > Everyone suggest this in 'google search'... :( But IMHO it's not an > option because: > > 1) As far as I know no one must have root access to run programs with > JMX agent. > 1.1) With this suggestion everyone must have root access (because only > root or sudo-ed user may change hostname and/or /etc/hosts) > 1.1.1) What if someone do not have root access to his PC (some > companies do not allow to install additional software without their > permissions)? > 1.1.2) Will you add the appropriate note to the 'Install' section in > Java manual/documentation? Or should everyone just google this > exception to find the fix of this issue? :) > > 2) Indeed Agent does not use hostname or it's IP to run JMX server > (please take a look at my original post) > 2.1) If Agent does not use it (i.e. hostname/IP) then why should it > depend on it? > > 3) Why should I change hostname if other services work correctly > without it? > 3.1) OS ignores that hostname can't be resolved to some IP and is > started successfully > 3.2) Apache does so too (because it listens on 0.0.0.0 in IPv4) > 3.3) SSH server as well ... > 3.4) etc., etc., etc. > 3.5) but java throws an exception > IMHO this does not follow the 'general' scheme ;) > > 4) How about JMX client (i.e. "Connecting to the JMX Agent > Programmatically ")? > http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdevg > > STR: > 4.1) server1 is behind NAT (example 1: on my VM, example 2: in Amazon > Cloud) > 4.2) port mapping is configured from external IP to the local one > (i.e. there is only local network IP on interface) > 4.3) I have associated my hostname (for instance, > server1.customer22.example.com) with 127.0.0.1 ( Is it a good idea to > do this in Amazon Cloud? IMHO no. ;) ) > 4.4) I start a program (Cassandra, Program4STR, etc.) via Agent > 4.5) if someone will change a record for > server1.customer22.example.com to the correct external IP then why > should agent connect to external IP instead of local one? :) > 4.5.1) if I run client on server1 then it's enough to connect to > localhost instead of external IP. Isn't it? > 4.5.2) if I start client on another PC then in any case I'll pass the > needed value in 'host' parameter to JMXServiceURL(...) > > 5) etc., etc., etc. (see examples from my original post and imagine > how client will connect to JMX server in each case) > > > Indeed the decision is 'up to you' but IMHO making the suggested > change will simplify everything, save time of many people (they will > not need to change hostname and/or /etc/hosts), google will deprecate > search of ' Error: Exception thrown by the agent : > java.net.MalformedURLException: Local host name unknown:' string and > at least several developers and system administrators will be happy > not to take care about hostname ... At least for Java and programs > which use Agent ;) > > > Thanks >