Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Hi Mandy, On 29/06/2016 12:28 PM, Mandy Chung wrote: On Jun 28, 2016, at 4:23 PM, David Holmes wrote: On 29/06/2016 8:43 AM, Kim Barrett wrote: Updated webrevs: Full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Jun 28, 2016, at 4:23 PM, David Holmes wrote: > > On 29/06/2016 8:43 AM, Kim Barrett wrote: >> Updated webrevs: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >> >> Incremental: >>

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

On 29/06/2016 8:43 AM, Kim Barrett wrote: Updated webrevs: Full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ Incremental: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ Did Reference not work? Just curious. I used to

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Jun 27, 2016, at 9:34 PM, Daniel D. Daugherty > wrote: > Other than the possible missing notify_all() in vmGCOperations.cpp, > this all looks great. Thanks Dan.

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Updated webrevs: Full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ Incremental: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ Still investigating the

Re: JDK 9 RFR of problem listing of several http2 tests

looks fine joe > On Jun 28, 2016, at 5:59 PM, Joseph D. Darcy wrote: > > PS The line for ErrorTest is better as > > +java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all > > Cheers, > > -Joe > > On 6/28/2016 2:57 PM, Joseph D. Darcy wrote: >> Hello,

Re: JDK 9 RFR of problem listing of several http2 tests

PS The line for ErrorTest is better as +java/net/httpclient/http2/ErrorTest.java 8158127 solaris-all,windows-all Cheers, -Joe On 6/28/2016 2:57 PM, Joseph D. Darcy wrote: Hello, Several of the http2 tests have been observed to fail intermittently with relatively high frequency on various

JDK 9 RFR of problem listing of several http2 tests

Hello, Several of the http2 tests have been observed to fail intermittently with relatively high frequency on various of our tests systems. I'd like to problem lists these tests while the underlying issues are being worked on. Patch below. Thanks, -Joe diff -r 5cfbcb4e6009

Re: RFR JDK-6233323: ZipEntry.isDirectory() may return false incorrectly

Looks fine, Roger On 6/28/2016 4:58 PM, Xueming Shen wrote: Hi, Please help codereview the change for JDK-6233323/8144977 issue: https://bugs.openjdk.java.net/browse/JDK-6233323 https://bugs.openjdk.java.net/browse/JDK-8144977 webrev:

RE: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Paul, Ok, you kind of got me convinced and it is also a quite simple modification. I changed from “java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number” to “java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)” like you suggested. The update is in

Re: RFR 8160439: Replace asserts in VarHandle.AccessMode with tests

Looks good. I'm still nervous about using assert in performance critical code due to hotspot bytecode count inlining heuristics. On Tue, Jun 28, 2016 at 3:50 AM, Paul Sandoz wrote: > Hi, > > Please review: > > >

Re: RFR 8054213: Class name repeated in output of Type.toString()

Hello Svetlana, I'm not convinced '$' should be replaced with '.' in this context as '.' is what the separator used in source code. In any case, the test should be restructured. I recommend declaring an annotation type to hold the expected to string output. You can them loop over the

Re: RFR 8054213: Class name repeated in output of Type.toString()

May be someone can find a minute? On 27.06.2016 21:25, Svetlana Nikandrova wrote: Kindly reminder On 24.06.2016 14:58, Svetlana Nikandrova wrote: Hello, let me try again with updated version of webrev: Webrev: http://cr.openjdk.java.net/~snikandrova/8054213/webrev.01/

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Jun 28, 2016, at 12:04 AM, David Holmes wrote: > > Hi Kim, > > I like all the removal of the pending-list-locker related code, but can't > really comment on the details of how it was replaced and interacts with all > the GC code. The interface to the Reference

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Jun 28, 2016, at 5:33 AM, Per Liden wrote: > Patch looks good. The only thing I don't feel qualified to review is the > initialization order change in thread.cpp, so I'll let others comments on > that. Thanks. I’ll be following up on that area. > I like the

RFR: 8056285: java/util/logging/CheckLockLocationTest.java java.lang.RuntimeException: Test failed: should have been able to create FileHandler for %t/writable-dir/log.log in writable directory.

Hi, JDK-8056285 has been sighted again (sigh). I strongly suspect a configuration issue but I have no proof. Here is an attempt at gathering some more data to nail down the root cause of the issue. JBS https://bugs.openjdk.java.net/browse/JDK-8056285 webrev:

Re: RFR: jsr166 jdk9 integration wave 7

On Tue, Jun 28, 2016 at 5:55 AM, Paul Sandoz wrote: > ConcurrentLinkedDeque > — > > linkFirst uses HEAD.compareAndSet, where as linkLast uses > TAIL.weakCompareAndSetVolatile, can the former use the weak variant too > since, as commented, failure is OK. > Well spotted!

Re: RFR: jsr166 jdk9 integration wave 7

On 06/28/2016 12:38 PM, Martin Buchholz wrote: On Tue, Jun 28, 2016 at 5:55 AM, Paul Sandoz > wrote: You can use VALUE.addAndGet same for other similar methods here and in other classes. Done: And, amazingly, not in conflict

Re: RFR: jsr166 jdk9 integration wave 7

On Tue, Jun 28, 2016 at 5:55 AM, Paul Sandoz wrote: > > AtomicInteger > — > > 185 public final int incrementAndGet() { > 186 return (int)VALUE.getAndAdd(this, 1) + 1; > 187 } > > > You can use VALUE.addAndGet same for other similar methods here and in >

Re: RFR(XS): 8160457: VersionProps.versionNumbers() is broken

Hi, WRT to testing - one thing that could be done (possibly in a followup patch) would be: class VersionProps { ... static List parseVersionNumbers(String versionNumber) { // parsing code goes there } static List versionNumbers() { return

Re: RFR(XS): 8160457: VersionProps.versionNumbers() is broken

That’s a great idea to add a test patching VersionProps generated with different version strings. We should file a JBS issue and add such a new test. Mandy > On Jun 28, 2016, at 9:07 AM, Daniel Fuchs wrote: > > Hi, > > WRT to testing - one thing that could be done

Re: RFR(XS): 8160457: VersionProps.versionNumbers() is broken

> On Jun 28, 2016, at 7:57 AM, Volker Simonis wrote: > > Hi, > > can somebody please review this trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8160457/ > https://bugs.openjdk.java.net/browse/JDK-8160457 > +1 > The problem is that

Re: RFR(XS): 8160457: VersionProps.versionNumbers() is broken

Hi, I'm terribly sorry, it seems this fell out from my patch to 816 as I was juggling patches back and forth between my workstation and my laptop. I did test manually with --with-version-patch for various numbers and was certain this was in in the final version and didn't re-test. I'd

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

Hi, what about this bug? It is still assigned to me and I would be happy to fix it as proposed in: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 If anybody has better ideas I'm open to transfer the bug to him :) But I still think this

Re: RFR: JDK-8160459 - jlink minor code clean up

> On Jun 28, 2016, at 8:09 AM, Jim Laskey (Oracle) > wrote: > > http://cr.openjdk.java.net/~jlaskey/8160459/webrev/index.html > > https://bugs.openjdk.java.net/browse/JDK-8160459 >

Re: RFR: JDK-8160459 - jlink minor code clean up

Looks good -Sundar On 6/28/2016 8:39 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8160459/webrev/index.html > > https://bugs.openjdk.java.net/browse/JDK-8160459 >

RFR: JDK-8160459 - jlink minor code clean up

http://cr.openjdk.java.net/~jlaskey/8160459/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160459

RFR(XS): 8160457: VersionProps.versionNumbers() is broken

Hi, can somebody please review this trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160457/ https://bugs.openjdk.java.net/browse/JDK-8160457 The problem is that VersionProps.versionNumbers() incorrectly parses a Java version string because it doesn't skip the separating dots. The

Re: RFR: jsr166 jdk9 integration wave 7

On Tue, Jun 28, 2016 at 5:55 AM, Paul Sandoz wrote: > > > CompletableFutureTest > — > > 3383 public void testRejectingExecutor() { > 3384 for (Integer v : new Integer[] { 1, null }) { > 3385 > 3386 final CountingRejectingExecutor e = new >

Re: RFR 8160439: Replace asserts in VarHandle.AccessMode with tests

Looks good. Best regards, Vladimir Ivanov On 6/28/16 1:50 PM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8160439-vh-access-mode-remove-assert/webrev/ This

Re: RFR 8160439: Replace asserts in VarHandle.AccessMode with tests

Hi Paul, Looks fine, very straightforward Regards, Roger On 6/28/2016 6:50 AM, Paul Sandoz wrote: Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8160439-vh-access-mode-remove-assert/webrev/

Re: RFR: jsr166 jdk9 integration wave 7

Hi, This first the part of my review that concentrates mostly on the implementation. Minor stuff. I don’t claim to know enough about the changes in FJ/CF, so i especially focused on the VH changes for those classes. Paul. CompletableFutureTest — 3383 public void testRejectingExecutor() {

RFR 8160439: Replace asserts in VarHandle.AccessMode with tests

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8160439-vh-access-mode-remove-assert/webrev/ This removes an assert that can load dependent locale-based classes too early in the

Re: JVM (1.8.0_91) crashes in Windows native code

Hi, On 06/24/2016 03:03 PM, Alex Kashchenko wrote: Hi Vinay, On 06/23/2016 06:56 PM, Vinay Purohit wrote: Hello, I'm not sure if this is the right forum for posting an issue we are experiencing with JRE 1.8.0_92. The JVM crashes in the Windows native code and generates a log (see

Re: RFR: jsr166 jdk9 integration wave 7

Hi Martin, Thanks, i will review carefully this week and do the necessary paper work for the FC exception required for API changes and the CCC. I found the cause of the test failure with java/util/Locale/Bug4152725.java. The constructor of VarHandle.AccessMode has some assert statements. These

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Hi Kim, On 2016-06-24 22:09, Kim Barrett wrote: Please review this change which moves the Reference pending list and locking from the java.lang.ref.Reference class into the VM. This includes elimination of the ReferencePendingListLocker mechanism in the VM. This fixes various fragility issues

Re: RFR[9]: 8158169: MethodHandles.dropArgumentsToMatch(...)

Hi Shilpi, in that case, please make sure to give the test that already covers the IAE a @bug annotation for this issue. Thanks, Michael > Am 27.06.2016 um 17:18 schrieb "shilpi.rast...@oracle.com" > : > > Thanks Michael and Paul for comments!! > > Yes we already