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

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 revi

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

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

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 wrote: > Hello, > > Already out for review on the build-dev list is a change to increment > JDK_MINOR_VERSION from 8

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

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 t

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

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 l

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

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 fr

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

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, Dece

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

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

[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 suppo

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

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 sun.misc.V

Re: Demo for Parallel Core Collection API

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. http://cr.openjdk.java.net/~ty

hg: jdk8/tl/jdk: 2 new changesets

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 ! src/share/classes/java/util/co

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

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 to

RFR of lang level code migration patches

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 mig

Re: RFR of lang level code migration patches

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

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: http://cr.openjdk.java.net/~

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

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

Created 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

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

+1 on all changes, except perhaps for this one in Collections.copy: ListIterator di=dest.listIterator(); ListIterator si=src.listIterator(); for (int i=0; iThe code is bizarre enough (calling next based on a range loop rather than hasNext()) to leave alone. On 12/1

Re: Bug in Long.parseUnsignedLong

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 to > track this issue.

Re: RFR of lang level code migration patches

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 jsr1

Re: RFR of lang level code migration patches

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 wrote: > Hi, > > Here are some patches that migrate some code to use more up to date language > fe

Re: Bug in Long.parseUnsignedLong

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

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

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

On 12/19/13 5:39 PM, Mandy Chung wrote: 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.ne

Re: RFR of lang level code migration patches

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

These look good to me. On Dec 19 2013, at 06:51 , Paul Sandoz 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. > > Compress catches

Re: Bug in Long.parseUnsignedLong

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) && secon

Re: Bug in Long.parseUnsignedLong

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 Wass

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

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: http://cr.openjdk.java.net/~plevart/jdk

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

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 , this is a sporadic failure and the web

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

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 c

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

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 h

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

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 unsure

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

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/ This is a one line fix that add -Xss to prevent StackOverflowError. Hi, I gu

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

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 i

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

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)

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

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/ This is a one line fix

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

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 a

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

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