Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-10 Thread Peter Levart
On 01/10/2014 12:59 AM, srikalyan chandrashekar wrote: David/Peter you are right, the logs trace came from passed run, i am trying to simulate the failure and get the logs for failed runs(2000+ runs done and still no failure), will get back to you once i have the data from failed run. Sorry

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-10 Thread Alan Bateman
On 09/01/2014 23:20, Tristan Yan wrote: Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code change is bringing this test back; add some debug info and try to avoid

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-10 Thread Staffan Larsen
On 10 jan 2014, at 09:34, Alan Bateman alan.bate...@oracle.com wrote: On 09/01/2014 23:20, Tristan Yan wrote: Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same JDK binaries). So intention for this code

RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail

2014-01-10 Thread Paul Sandoz
Hi, A small tweak is required to a recent Stream-based test i added to stop some internal lambda-based ser/derialization (SAND) tests barfing since the test is hostile to ser/derialization, and infact i should have probably written the test like below in the first place. Kumar has verified it

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Alan Bateman
On 10/01/2014 06:31, Dan Xu wrote: Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007 This looks good, the only one that isn't clear

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-10 Thread David Holmes
On 10/01/2014 6:40 PM, Staffan Larsen wrote: On 10 jan 2014, at 09:34, Alan Bateman alan.bate...@oracle.com wrote: On 09/01/2014 23:20, Tristan Yan wrote: Hi David I wasn't able to reproduce this failure either in local or in our same binaries running(This is a continuous running with same

Re: RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm

2014-01-10 Thread Alan Bateman
On 10/01/2014 10:37, David Holmes wrote: I'm not sure what is actually being proposed. I don't really see anything that would help diagnoze the original issue. But bring back the test - maybe this was a bug elsewhere that has now been fixed. I think the proposal is as we said, more diagnostic

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-10 Thread Peter Levart
On 01/10/2014 09:31 AM, Peter Levart wrote: Since we suspect there's something wrong with exception handling in interpreter, I devised a hypothetical reproducer that tries to simulate ReferenceHandler in many aspects, but doesn't require to be a ReferenceHandler:

RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-10 Thread Paul Sandoz
Hi, When we added the List.sort method the default implementation deferred to Collections.sort. This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by ArrayList.sort. To resolve this the

Re: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail

2014-01-10 Thread Chris Hegarty
Looks fine to me. I don't think AtomicLong was ever needed here. -Chris. On 10/01/14 10:01, Paul Sandoz wrote: Hi, A small tweak is required to a recent Stream-based test i added to stop some internal lambda-based ser/derialization (SAND) tests barfing since the test is hostile to

Re: RFR 8031428 CountTest causes lambda Ser/Derialization tests to fail

2014-01-10 Thread Paul Sandoz
On Jan 10, 2014, at 12:48 PM, Chris Hegarty chris.hega...@oracle.com wrote: Looks fine to me. Thanks. I don't think AtomicLong was ever needed here. It was crudely used as a holder of the count, since captured refs are (effectively) final, and not for it's concurrent properties as i

Re: (reflect) Accessing members of inner annotations types

2014-01-10 Thread Gunnar Morling
Hi, Many thanks for the investigation and suggested workarounds. Bean Validation recommends to declare an inner @List annotation to specify several constraints of the same type on a given element, but its ok to deviate from that pattern in the rare cases of package-private constraint types. I

RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-10 Thread Paul Sandoz
Hi, Some tweaks to the Stream forEachOrdered operation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ The first tweak is to size the CHM used in ForEachOrderedTask, this avoids concurrent resizes and the costs associated with those. The second tweak is to

Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-10 Thread Alan Bateman
On 10/01/2014 11:21, Paul Sandoz wrote: Hi, When we added the List.sort method the default implementation deferred to Collections.sort. This is the wrong way around, since any existing use of Collections.sort say with ArrayList will not avail of the optimal implementation provided by

Request for approval for bug #8031488

2014-01-10 Thread Iaroslav Savytskyi
Hello, I would like to request for approval for this fix. This is simple revert of the changes which caused the issue. I’ve returned back synchronization and removed volatile. So now serialVersionUID is the same as before. Bug: https://bugs.openjdk.java.net/browse/JDK-8031488 Webrev:

Re: Request for approval for bug #8031488

2014-01-10 Thread Iaroslav Savytskyi
Hi, Alan, You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I’m fixing this now is, that some time ago I fix this synchronization issue (synchronized setter without synchronized getter). After that I got this bug. We had internal discussions if I

RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread roger riggs
Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev: http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ [1]

Re: Request for approval for bug #8031488

2014-01-10 Thread Alan Bateman
On 10/01/2014 15:08, Iaroslav Savytskyi wrote: Hi, Alan, You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I’m fixing this now is, that some time ago I fix this synchronization issue (synchronized setter without synchronized getter). After that

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread Chris Hegarty
Thank you Roger, much appreciated. I think Dan has a change in flight that could be simplified a bit by using these. -Chris. On 10/01/14 15:37, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and

Re: Request for approval for bug #8031488

2014-01-10 Thread Iaroslav Savytskyi
On 10 Jan 2014, at 16:36, Alan Bateman alan.bate...@oracle.com wrote: On 10/01/2014 15:08, Iaroslav Savytskyi wrote: Hi, Alan, You are absolutely right. Unfortunately the things a little bit more complicated. The reason why I’m fixing this now is, that some time ago I fix this

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread Alan Bateman
On 10/01/2014 15:37, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev:

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread roger riggs
Hi Dan, Just pushed are macros in jni_util.h to do the same function as your new macros. Please update to use the common macros instead of introducing new ones. Style wise, I would avoid mixing binary operators (!) with pointers. it is clearer to compare with NULL. (The CHECK_NULL macro will

JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013

2014-01-10 Thread Miroslav Kos
Hi, this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script jdk8/make/scripts/update_copyright_year.sh it is necessary to use option -d date for commit. I tested that and it seems to work perfect. I used following: [2012

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread Michael McMahon
On 10/01/14 15:37, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev:

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread Mandy Chung
On 1/10/2014 7:37 AM, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev:

JDK-9 RFR for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early.

2014-01-10 Thread Daniel Fuchs
Hi, Please find below a trivial fix for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early. https://bugs.openjdk.java.net/browse/JDK-8031525 Hopefully that's the last of its kind - (see https://bugs.openjdk.java.net/browse/JDK-8029595). webrev:

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
Thanks, Chris. Right, I don't find any usage of getThreadStateValues, so it is simpler to just remove it. -Dan On 01/09/2014 11:49 PM, Chris Hegarty wrote: Looks ok to me. I presume getThreadStateValues is simply no longer needed. -Chris. On 10 Jan 2014, at 06:31, Dan Xu

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
On 01/10/2014 02:32 AM, Alan Bateman wrote: On 10/01/2014 06:31, Dan Xu wrote: Hi All, Please review the fix for JNI pending exception issues reported in jdk-8029007. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8029007

Re: JDK-9 RFR for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early.

2014-01-10 Thread Chris Hegarty
Looks good to me Daniel. -Chris. On 10 Jan 2014, at 17:47, Daniel Fuchs daniel.fu...@oracle.com wrote: Hi, Please find below a trivial fix for 8031525: Logger created in test/tools/jar/UpdateManifest.java might get gc'ed too early.

Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

2014-01-10 Thread Mike Duigou
The implementation looks good. I would move construction of the listIterator to before the toArray() for detection of concurrent modification (growing of the list). I believe we should fix this for 8 if possible. Mike On Jan 10 2014, at 03:21 , Paul Sandoz paul.san...@oracle.com wrote: Hi,

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread roger riggs
Hi Dan, One other comment, instead of changing the return type of the setStaticIntField just return and the caller should check for exceptions and return. See jni.h: CHECK_EXCEPTION(env) Roger On 1/10/2014 11:40 AM, roger riggs wrote: Hi Dan, Just pushed are macros in jni_util.h to do the

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
Hi Roger, My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using return values. As for the style, actually I prefer the

Re: RFR: (8030875) Macros for checking and returning on exceptions

2014-01-10 Thread roger riggs
Hi Mandy, Good point; I'll create another issue to do that update. (I should have waited a bit longer for comments.) Roger On 1/10/2014 12:41 PM, Mandy Chung wrote: On 1/10/2014 7:37 AM, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Chris Hegarty
On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote: Hi Roger, My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are useful when I cannot decide the pending exception state by just using

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-10 Thread Mike Duigou
On Jan 10 2014, at 05:42 , Paul Sandoz paul.san...@oracle.com wrote: Hi, Some tweaks to the Stream forEachOrdered operation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ The first tweak is to size the CHM used in ForEachOrderedTask, this avoids

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
Yes, you are right. I just found this macro. It looks very handy to use. Thanks! -Dan On 01/10/2014 09:59 AM, roger riggs wrote: Hi Dan, One other comment, instead of changing the return type of the setStaticIntField just return and the caller should check for exceptions and return. See

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-10 Thread Paul Sandoz
On Jan 10, 2014, at 7:11 PM, Mike Duigou mike.dui...@oracle.com wrote: The second tweak is to consolidate the reporting of elements to within the ForEachOrderedTask.tryComplete method. I have also removed the inconsistently applied synchronized block. Either we apply it consistently to

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Mike Duigou
On Jan 10 2014, at 10:09 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote: Hi Roger, My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

2014-01-10 Thread Dan Xu
Thank you for all the feedback. I have updated my changes to use CHECK_EXCEPTION_RETURN and CHECK_EXCEPTION macro recently added into jni_util.h. I also removed else block in function setStaticIntField() in Version.c since (*env)-GetStaticFieldID will throw a same exception if the field cannot

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-10 Thread srikalyan chandrashekar
Hi Peter the version you provided ran indefinitely(i put a 10 minute timeout) and the program got interrupted(no error), even if there were to be an error you cannot print the string of thread to console(these have been attempted earlier). - The test's running on interpreter mode, what i am

8031494: [launcher] java launcher should check for JNI Pending exceptions.

2014-01-10 Thread Kumar Srinivasan
Hi, Please review fixes for launcher correctness wrt. JNI calls. http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/ Thanks Kumar