FYI, regression test exclusion as temporary part of JDK_MINOR_VERSION increment for JDK 9

2013-12-19 Thread Joe Darcy
Hello, Already out for review on the build-dev list is a change to increment JDK_MINOR_VERSION from 8 to 9 as part of getting JDK 9 underway. However, due to HotSpot bug JDK-8030656 Bad version check for parameter information in src/share/vm/classfile/javaClasses.cpp (also out for

Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names

2013-12-19 Thread Masayoshi Okutsu
On 12/18/2013 6:43 PM, Aleksej Efimov wrote: Hi, Please help to review a fix [1] for 8025051 bug [2]. The following fix includes: Common to all modified files: - All year ranges in the copyright header should be modified accordingly. - The translation of time zone generic names were added

Re: FYI, regression test exclusion as temporary part of JDK_MINOR_VERSION increment for JDK 9

2013-12-19 Thread Chris Hegarty
Looks good to me Joe. This change, to me at least, demonstrates the power of the ProblemList.txt. It is a really useful mechanism. -Chris. On 19 Dec 2013, at 07:59, Joe Darcy joe.da...@oracle.com wrote: Hello, Already out for review on the build-dev list is a change to increment

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 4/12/2013 7:00 PM, Alan Bateman wrote: On 04/12/2013 08:24, Jeroen Frijters wrote: Hi, I'd like to propose to change Class.checkInitted() to check if the VM initialization has completed by using sun.misc.VM.isBooted() instead of System.out != null. This should be changed (I can only guess

Re: RFR: java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java failing again

2013-12-19 Thread Daniel Fuchs
On 12/18/13 9:35 PM, Mandy Chung wrote: On 12/17/2013 3:57 AM, Daniel Fuchs wrote: Hi, Please find below a fix for what I believe is a test bug. I plan to push this in JDK 9 dev. https://bugs.openjdk.java.net/browse/JDK-8030187 This seems to be a very intermittent failure. It looks as if a

RE: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread Jeroen Frijters
System.out can be null, because System.setOut(null) is legal. Regards, Jeroen From: David Holmes [mailto:david.hol...@oracle.com] Sent: Thursday, December 19, 2013 11:14 To: Alan Bateman Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net Subject: Re: Request: Remove System.out check from

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 19/12/2013 9:19 PM, Jeroen Frijters wrote: System.out can be null, because System.setOut(null) is legal. Ah I see. That isn't an initialization issue but a post-initialization issue. Thanks, David Regards, Jeroen From: David Holmes [mailto:david.hol...@oracle.com] Sent: Thursday,

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread Alan Bateman
On 19/12/2013 10:13, David Holmes wrote: Not necessarily. The question is, are there any code paths that lead to checkInitted being called after setOut0(newPrintStream(fdOut, props.getProperty(sun.stdout.encoding))) but before the call to sun.misc.VM.booted(). If so these would fail under

New default for ForkJoinPool.commonPool on systems with SecurityManagers

2013-12-19 Thread Doug Lea
[Cross-posting on core-libs-dev and concurrency-interest.] The ForkJoinPool common pool is used in JDK8 for all parallel Stream operations, parallel sorting, etc. When designing this, we knew that in some managed environments, administrators might want to limit or disable parallelism, so we

Re: Request: Remove System.out check from Class.checkInitted()

2013-12-19 Thread David Holmes
On 19/12/2013 9:59 PM, Alan Bateman wrote: On 19/12/2013 10:13, David Holmes wrote: Not necessarily. The question is, are there any code paths that lead to checkInitted being called after setOut0(newPrintStream(fdOut, props.getProperty(sun.stdout.encoding))) but before the call to

Re: Demo for Parallel Core Collection API

2013-12-19 Thread Tristan Yan
Hi Paul And Everyone Sorry for getting back late. I took Paul's suggestion and have written other two demos which presents usage of parallel computation. One is using Monte-Carlo to calculate value of PI. Other is find a big prime by given length. Please review it.

hg: jdk8/tl/jdk: 2 new changesets

2013-12-19 Thread chris . hegarty
Changeset: e2bdddb8bedf Author:dl Date: 2013-12-19 10:31 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2bdddb8bedf 8026155: Enhance ForkJoin pool Reviewed-by: chegar, alanb, ahgross ! src/share/classes/java/util/concurrent/ForkJoinPool.java !

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-19 Thread Alan Bateman
On 14/12/2013 11:25, Peter Levart wrote: It's unfortunate that a lambda debugging feature prevents us from using a basic language feature in j.u.logging code. As far as I know, java.lang.invoke.ProxyClassesDumper is only used if 'jdk.internal.lambda.dumpProxyClasses' system property is set

RFR of lang level code migration patches

2013-12-19 Thread Paul Sandoz
Hi, Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback. This is motivated from Brian's patches to lang tools. I focused just on java.util, minus the concurrent packages, and i used the IDE to assist in the code

Re: RFR of lang level code migration patches

2013-12-19 Thread Daniel Fuchs
Hi Paul, I looked at the modifications in java.util.logging and they look both sensible and desirable. Had to look at the code for Objects.toString(Object,Object) as I had never used that before :-) Thanks for taking care of that, -- daniel On 12/19/13 3:51 PM, Paul Sandoz wrote: Hi, Here

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-19 Thread Peter Levart
On 12/18/2013 11:55 PM, Mandy Chung wrote: On 12/18/2013 9:03 AM, Peter Levart wrote: Hi Mandy, Daniel, Here's yet another variant that reduces the doPrivileged code to just Handler's setters. This way no LogManager methods are invoked under elevated privilege:

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-19 Thread Daniel Fuchs
Hi Peter, Good idea to add a package constructor in Handler. It looks much cleaner than the configure method. Good tests too - thanks for adding that! To access files with JPRT there is a simpler manner (though what you have looks good). JPRT sets a system property test.src which point at the

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread roger riggs
Created JDK-8030814 https://bugs.openjdk.java.net/browse/JDK-8030814 to track this issue. Roger On 12/18/2013 6:52 PM, Louis Wasserman wrote: Derp. Here is the test case: import java.math.BigInteger; public class UnsignedLongBug { public static void main(String[] args) { try {

Re: RFR: java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java failing again

2013-12-19 Thread Mandy Chung
On 12/19/2013 3:04 AM, Daniel Fuchs wrote: On 12/18/13 9:35 PM, Mandy Chung wrote: On 12/17/2013 3:57 AM, Daniel Fuchs wrote: Hi, Please find below a fix for what I believe is a test bug. I plan to push this in JDK 9 dev. https://bugs.openjdk.java.net/browse/JDK-8030187 This seems to be a

Re: RFR of lang level code migration patches

2013-12-19 Thread Brian Goetz
+1 on all changes, except perhaps for this one in Collections.copy: ListIterator? super T di=dest.listIterator(); ListIterator? extends T si=src.listIterator(); for (int i=0; isrcSize; i++) { di.next(); di.set(si.next());

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Brian Burkhalter
Thanks, you saved me the trouble. I already verified it yesterday myself. Brian On Dec 19, 2013, at 8:26 AM, roger riggs wrote: Created JDK-8030814 https://bugs.openjdk.java.net/browse/JDK-8030814 to track this issue.

Re: RFR of lang level code migration patches

2013-12-19 Thread Brian Goetz
Paul deliberately stayed away from the JUC classes. Can we get a definitive list of non-JUC classes that primarily live in the JSR166 CVS? On 12/19/2013 11:48 AM, Martin Buchholz wrote: (as always) Please don't modify jsr166 classes (ArrayDeque) here, since they are maintained upstream in

Re: RFR of lang level code migration patches

2013-12-19 Thread Chris Hegarty
I looked over the patch files, and they look good to me. Limiting each webrev to a single language feature makes reviewing quite straight forward. -Chris. On 19 Dec 2013, at 14:51, Paul Sandoz paul.san...@oracle.com wrote: Hi, Here are some patches that migrate some code to use more up to

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Paul Sandoz
Hi, I think the logic for overflow when using the compareUnsigned is incorrect in Long: long first = parseLong(s.substring(0, len - 1), radix); int second = Character.digit(s.charAt(len - 1), radix); if (second 0) { throw new

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Brian Burkhalter
On Dec 19, 2013, at 9:36 AM, Paul Sandoz wrote: I think the logic for overflow when using the compareUnsigned is incorrect in Long: […] long result = first * radix + second; if (compareUnsigned(result, first) 0) { I concur and verified that yesterday by

Re: RFR of lang level code migration patches

2013-12-19 Thread Alan Bateman
On 19/12/2013 14:51, Paul Sandoz wrote: : I ran all the j.u. tests locally and there were no regressions. That's the main thing with changes like this. I skimmed over the changes too and they look okay. I'm sometimes wary of IDEs re-arranging things but there's nothing here. It would be good

Re: RFR of lang level code migration patches

2013-12-19 Thread Mike Duigou
These look good to me. On Dec 19 2013, at 06:51 , Paul Sandoz paul.san...@oracle.com wrote: Hi, Here are some patches that migrate some code to use more up to date language features. I will create a bug later on after feedback. This is motivated from Brian's patches to lang tools.

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Brian Burkhalter
Upon inspection only that indeed looks correct. Thanks … On Dec 19, 2013, at 10:28 AM, Louis Wasserman wrote: Here's one approach that works: there is overflow iff compareUnsigned(first, divideUnsigned(MAX_UNSIGNED, radix)) 0 || (first == divideUnsigned(MAX_UNSIGNED, radix) second

Re: Bug in Long.parseUnsignedLong

2013-12-19 Thread Brian Burkhalter
Here's a formalization of the suggested fix: http://cr.openjdk.java.net/~bpb/8030814/webrev/ It works against the test case. Brian On Dec 19, 2013, at 11:26 AM, Brian Burkhalter wrote: Upon inspection only that indeed looks correct. Thanks … On Dec 19, 2013, at 10:28 AM, Louis

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-19 Thread Mandy Chung
On 12/19/13 7:49 AM, Peter Levart wrote: Hi Mandy, Daniel, I didn't like the package-protected getters either. So here's another variant that replaces Handler.configure() method with a package-protected constructor which is chained from JDK subclasses:

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

2013-12-19 Thread David Holmes
Hi Kalyan, This is not a hotspot issue so I'm moving this to core-libs, please drop hotspot from any replies. On 20/12/2013 6:26 AM, srikalyan wrote: Hi all, I have been working on the bug JDK-8022321 https://bugs.openjdk.java.net/browse/JDK-8022321 , this is a sporadic failure and the

Re: RFR [6968459] JNDI timeout fails before timeout is reached

2013-12-19 Thread David Holmes
If you track the elapsed waiting time using System.nanoTime you do not need to be concerned whether anyone messes with the TOD clock. David On 4/12/2013 2:05 AM, Peter Levart wrote: On 12/03/2013 03:35 PM, Ivan Gerasimov wrote: Hi Peter! Thank you for your review! You are right, the patch

Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

2013-12-19 Thread Stuart Marks
Hi Tristan, Changes mostly look good. There is an ignored InterruptedException in both versions of UseCustomSocketFactory.java, but that was there already; it's not clear what should be done in this case anyway. This is something to keep in mind for a future cleanup. Hm, some duplicate code

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

2013-12-19 Thread srikalyan chandrashekar
Hi David Thanks for your comments, the unguarded part(clean and enqueue) in the Reference Handler thread does not seem to create any new objects, so it is the application(the test in this case) which is adding objects to heap and causing the Reference Handler to die with OOME. I am still

Re: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

2013-12-19 Thread Stuart Marks
On 12/18/13 10:25 PM, Tristan Yan wrote: Hi Everyone Please help to review the fix for JDK-8030284. http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/ http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/ This is a one line fix that add -Xss to prevent StackOverflowError. Hi, I

Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

2013-12-19 Thread Tristan Yan
Thanks Stuart I changed ReadTimeoutTest.java only apply CountdownLatch part. Please review. http://cr.openjdk.java.net/~tyan/JDK-7168267/webrev.02/ Thank you Tristan On 12/20/2013 10:47 AM, Stuart Marks wrote: Hi Tristan, Changes mostly look good. There is an ignored InterruptedException

Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'

2013-12-19 Thread David Holmes
Sorry Kalyan but I don't see the need for all the incidental changes if the primary change is to just increase the iterations. I also don't see why you need to do anything for BrokenBarrierException as it is not expected to happen and the test should just fail if it does. David On 10/12/2013

Re: RFR for JDK-6963118 Intermittent test failure: test/java/nio/channels/Selector/Wakeup.java fail intermittently (win)

2013-12-19 Thread David Holmes
This should probably be reviewed by the nio-dev folk. Increasing the timeouts seems okay but how confident are you that this is sufficient for a wide range of platforms. In other tests we often see timeouts of a few seconds get extended even further, so three seconds is not so big. Also the

Re: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

2013-12-19 Thread David Holmes
Hi Stuart, On 20/12/2013 1:06 PM, Stuart Marks wrote: On 12/18/13 10:25 PM, Tristan Yan wrote: Hi Everyone Please help to review the fix for JDK-8030284. http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/ http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/ This is a one line fix

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

2013-12-19 Thread Mandy Chung
Hi Srikalyan, Maybe you can get add an uncaught handler to see if you can get any information. I ran it for 1000 times but not able to duplicate the failure. Did you run it with jtreg (I didn't)? Below is the patch to install a thread's uncaught handler that you can take and try. diff --git

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

2013-12-19 Thread David Holmes
On 20/12/2013 12:57 PM, srikalyan chandrashekar wrote: Hi David Thanks for your comments, the unguarded part(clean and enqueue) in the Reference Handler thread does not seem to create any new objects, so it is the application(the test in this case) which is adding objects to heap and causing the