Re: 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

hg: jdk8/tl/jdk: 8008688: Make MethodHandleInfo public

Changeset: 4bdbd1fabea4 Author:rfield Date: 2013-09-03 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbd1fabea4 8008688: Make MethodHandleInfo public Summary: A major overhaul to MethodHandleInfo and method handles in general. Reviewed-by: vlivanov, twisti Contribute

hg: jdk8/tl/jdk: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

Changeset: 2cdd1078f45b Author:dholmes Date: 2013-09-03 23:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdd1078f45b 8024140: [TESTBUG] Profile based regression test groups for jdk repo Reviewed-by: alanb, chegar ! test/TEST.groups

Re: 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: 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?

hg: jdk8/tl/langtools: 8023545: Misleading error message when using diamond operator with private constructor

Changeset: 9be0afbdf244 Author:vromero Date: 2013-09-03 23:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9be0afbdf244 8023545: Misleading error message when using diamond operator with private constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/co

hg: jdk8/tl/langtools: 8023389: Javac fails to infer type for lambda used with intersection type and wildcards

Changeset: fb5a846c4a49 Author:vromero Date: 2013-09-03 23:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb5a846c4a49 8023389: Javac fails to infer type for lambda used with intersection type and wildcards Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadam.

hg: jdk8/tl/jdk: 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect

Changeset: 06b01083ebd7 Author:henryjen Date: 2013-09-03 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06b01083ebd7 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect Reviewed-by: alanb ! src/share/classes/jav

hg: jdk8/tl: 8024200: handle hg wrapper with space after #!

Changeset: 6d7f27953da6 Author:mduigou Date: 2013-09-03 15:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6d7f27953da6 8024200: handle hg wrapper with space after #! Reviewed-by: tbell ! common/bin/hgforest.sh

hg: jdk8/tl/langtools: 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied

Changeset: 438547d895dc Author:vromero Date: 2013-09-04 00:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/438547d895dc 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied Reviewed-by: jjg, v

hg: jdk8/tl/corba: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets

Changeset: af8e5bc3a150 Author:coffeys Date: 2013-09-03 22:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/af8e5bc3a150 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar ! src/share/classes/com/sun/corba/se/impl/transport

hg: jdk8/tl/jdk: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets

Changeset: 5920155dd080 Author:coffeys Date: 2013-09-03 22:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5920155dd080 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar + test/com/sun/corba/transport/KeepAliveSockets.java

hg: jdk8/tl/jdk: 8017513: Support for closeable streams; ...

Changeset: 2e8d51a5596b Author:henryjen Date: 2013-09-03 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e8d51a5596b 8017513: Support for closeable streams 8022237: j.u.s.BaseStream.onClose() has an issue in implementation or requires spec clarification 8022572: Same e

hg: jdk8/tl/jdk: 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos

Changeset: 3db3ae4e0853 Author:henryjen Date: 2013-09-03 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3db3ae4e0853 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Reviewed-by: mduigou ! src/share/classes/java/util/strea

hg: jdk8/tl/jdk: 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang

Changeset: 4bdbe25b1e04 Author:mduigou Date: 2013-09-03 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbe25b1e04 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang Reviewed-by: alanb, mchung ! test/TEST.groups

hg: jdk8/tl/jdk: 8022176: Weaken contract of java.lang.AutoCloseable

Changeset: 77a8c4ad516c Author:henryjen Date: 2013-08-28 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a8c4ad516c 8022176: Weaken contract of java.lang.AutoCloseable Reviewed-by: alanb, martin, mduigou, psandoz Contributed-by: brian.go...@oracle.com ! src/share/clas

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: 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: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure

Looks good, but I think it's better for tests to spin forever if they can't reach a state and let the test harness deal with it, but I'm fine with it, since it was that way before. Erik Jaroslav Bachorik skrev 2013-09-03 13:15: Please, review the following patch of the intermittently failin

Re: 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

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: 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

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