Re: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

On 09/04/2013 04:24 AM, Mandy Chung wrote: > Hi Jaroslav, > > Like Daniel and David said, CyclicBarrier and other j.u.concurrent > utility seem a good replacement with the ThreadExecutionSynchronizer > class. ThreadMXBean/Locks.java was written prior to j.u.concurrent > added to the platform (bot

Re: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

Hi Jaroslav, Like Daniel and David said, CyclicBarrier and other j.u.concurrent utility seem a good replacement with the ThreadExecutionSynchronizer class. ThreadMXBean/Locks.java was written prior to j.u.concurrent added to the platform (both java.util.concurrent and java.lang.management we

Re: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

Hi Jaroslav, On 3/09/2013 11:02 PM, Jaroslav Bachorik wrote: On 09/03/2013 02:10 PM, Daniel Fuchs wrote: Hi Jaroslav, Have you considered replacing the ThreadExecutionSynchronizer with a plain (and more reliable) CyclicBarrier or Phaser object?

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 14:36, Jaroslav Bachorik wrote: : Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean not cleaning up the threads and not running in "othervm" mode and made them running in "othervm" mode. There are 5 such tests. IMO, for 5 tests it is worth to go for the simple

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 09/03/2013 01:54 PM, Alan Bateman wrote: > On 03/09/2013 12:26, Jaroslav Bachorik wrote: >> : >> Hm, actually there are 6 other tests using the LockingThread class which >> leaves the threads running. So all those tests should be made running in >> "othervm" mode. >> >> Does increasing the numbe

Re: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

On 09/03/2013 02:10 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > Have you considered replacing the ThreadExecutionSynchronizer with > a plain (and more reliable) CyclicBarrier or Phaser object? > > > >

Re: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

Hi Jaroslav, Have you considered replacing the ThreadExecutionSynchronizer with a plain (and more reliable) CyclicBarrier or Phaser object?

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 12:26, Jaroslav Bachorik wrote: : Hm, actually there are 6 other tests using the LockingThread class which leaves the threads running. So all those tests should be made running in "othervm" mode. Does increasing the number of tests running in "othervm" mode have any negative conseq

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 09/03/2013 01:26 PM, Jaroslav Bachorik wrote: > On 09/03/2013 12:57 PM, Alan Bateman wrote: >> On 03/09/2013 09:02, Jaroslav Bachorik wrote: >>> Please, review the following patch: >>> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 09/03/2013 12:57 PM, Alan Bateman wrote: > On 03/09/2013 09:02, Jaroslav Bachorik wrote: >> Please, review the following patch: >> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 >> >> It addresses the problem of the test not

jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

Please, review the following patch of the intermittently failing test: http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-6815130 Sometimes the ThreadExecutionSynchronizer class failes to achieve the desired synchronization (due to possible da

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 03/09/2013 09:02, Jaroslav Bachorik wrote: Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the created threads at exit. It does so

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 9/3/13 10:02 AM, Jaroslav Bachorik wrote: It addresses the problem of the test not properly cleaning up the created threads at exit. It does so by running the test in "othervm" mode. Although it is possible to modify the test to cleanup the threads at exit it would add more complexity to the t

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

Looks good, simple but workable solution! Shanliang Jaroslav Bachorik wrote: Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the cr

Re: jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

On 09/03/2013 09:02 AM, Jaroslav Bachorik wrote: Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the created threads at exit. It does

jmx-dev RFR: 8004179: test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java doesn't clean up

Please, review the following patch: http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8004179 It addresses the problem of the test not properly cleaning up the created threads at exit. It does so by running the test in "othervm" mode. Although