From chris.hegarty at oracle.com Thu Sep 1 05:45:47 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Sep 2011 05:45:47 +0000 Subject: hg: jdk8/tl/jdk: 7014860: Socket.getInputStream().available() not clear for shutdown input Message-ID: <20110901054606.0B82E47290@hg.openjdk.java.net> Changeset: a5a28b040714 Author: chegar Date: 2011-09-01 06:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5a28b040714 7014860: Socket.getInputStream().available() not clear for shutdown input Reviewed-by: alanb, michaelm ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketImpl.java + test/java/net/Socket/ShutdownInput.java From chris.hegarty at oracle.com Thu Sep 1 13:46:46 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Sep 2011 13:46:46 +0000 Subject: hg: jdk8/tl/jdk: 7041800: URI.equals may incorrectly return true with escaped octets Message-ID: <20110901134708.4CB21472A7@hg.openjdk.java.net> Changeset: fcb33500b325 Author: chegar Date: 2011-09-01 13:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fcb33500b325 7041800: URI.equals may incorrectly return true with escaped octets Reviewed-by: alanb, michaelm ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java From kumar.x.srinivasan at oracle.com Thu Sep 1 16:57:39 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 01 Sep 2011 16:57:39 +0000 Subject: hg: jdk8/tl/langtools: 7073631: (javac) javac parser improvements for error position reporting Message-ID: <20110901165743.7AB60472B0@hg.openjdk.java.net> Changeset: 04f983e3e825 Author: ksrini Date: 2011-09-01 09:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/04f983e3e825 7073631: (javac) javac parser improvements for error position reporting Summary: JavacParser improvements for NetBeans, improved by LangTools. Reviewed-by: mcimadamore, jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out ! test/tools/javac/TryWithResources/TwrLint.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/diags/examples/EmptyCharLiteral.java + test/tools/javac/parser/netbeans/JavacParserTest.java From xueming.shen at oracle.com Thu Sep 1 18:42:59 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 01 Sep 2011 11:42:59 -0700 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized Message-ID: <4E5FD233.4030103@oracle.com> Hi, This is a forward porting. Same fix has been in jdk5/6, and will be in jdk 7u2 later. http://cr.openjdk.java.net/~sherman/6898310/webrev The change itself is relative simple. And given its race-condition nature, no reliable regression test case is provided. Thanks! -Sherman From jim.holmlund at sun.com Thu Sep 1 21:41:13 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 01 Sep 2011 21:41:13 +0000 Subject: hg: jdk8/tl/langtools: 7086071: tools/javac/7079713/TestCircularClassfile.java fails on windows Message-ID: <20110901214117.D2A61472C2@hg.openjdk.java.net> Changeset: a45d78d26450 Author: jjh Date: 2011-09-01 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a45d78d26450 7086071: tools/javac/7079713/TestCircularClassfile.java fails on windows Summary: delete file before renaming another file to it Reviewed-by: jjg ! test/tools/javac/7079713/TestCircularClassfile.java From joe.darcy at oracle.com Fri Sep 2 06:00:55 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Sep 2011 06:00:55 +0000 Subject: hg: jdk8/tl/jdk: 7082971: More performance tuning of BigDecimal and other java.math classes Message-ID: <20110902060120.1E673472D9@hg.openjdk.java.net> Changeset: ffada2ce20e5 Author: darcy Date: 2011-09-01 23:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffada2ce20e5 7082971: More performance tuning of BigDecimal and other java.math classes Reviewed-by: darcy Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigDecimal/DivideMcTests.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/RangeTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/math/BigDecimal/ToPlainStringTests.java From Alan.Bateman at oracle.com Fri Sep 2 10:51:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Sep 2011 11:51:34 +0100 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E5FD233.4030103@oracle.com> References: <4E5FD233.4030103@oracle.com> Message-ID: <4E60B536.1070105@oracle.com> Xueming Shen wrote: > Hi, > > This is a forward porting. Same fix has been in jdk5/6, and will be in > jdk 7u2 later. > > http://cr.openjdk.java.net/~sherman/6898310/webrev > > The change itself is relative simple. And given its race-condition > nature, no reliable > regression test case is provided. This looks okay to me. -Alan. From forax at univ-mlv.fr Fri Sep 2 11:17:46 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 02 Sep 2011 13:17:46 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60B536.1070105@oracle.com> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> Message-ID: <4E60BB5A.1030700@univ-mlv.fr> On 09/02/2011 12:51 PM, Alan Bateman wrote: > Xueming Shen wrote: >> Hi, >> >> This is a forward porting. Same fix has been in jdk5/6, and will be >> in jdk 7u2 later. >> >> http://cr.openjdk.java.net/~sherman/6898310/webrev >> >> The change itself is relative simple. And given its race-condition >> nature, no reliable >> regression test case is provided. > This looks okay to me. > > -Alan. Arghhh, next() can return null ! CharsetProvider provider = ... Iterator it = provider.charsets(); Iterator it2 = provider.charsets(); Charset charset = it.next(); provider.deleteCharset(charset.name(), ...) System.out.println(it2.next()); // print null even if I'm not sure a lot of CharsetProvider actually calls deleteCharset there is a possible bug here. cheers, R?mi From Alan.Bateman at oracle.com Fri Sep 2 11:34:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Sep 2011 12:34:26 +0100 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60BB5A.1030700@univ-mlv.fr> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> Message-ID: <4E60BF42.6050200@oracle.com> R?mi Forax wrote: > > Arghhh, next() can return null ! > > CharsetProvider provider = ... > Iterator it = provider.charsets(); > Iterator it2 = provider.charsets(); > Charset charset = it.next(); > provider.deleteCharset(charset.name(), ...) > System.out.println(it2.next()); // print null > > even if I'm not sure a lot of CharsetProvider actually calls > deleteCharset > there is a possible bug here. > deleteCharset isn't a public method so I don't think this can happen. I don't disagree that that the iterator code should be re-written, just thinking it's separate from fixing the race condition. -Alan. From Ulf.Zibis at gmx.de Fri Sep 2 11:40:01 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Sep 2011 13:40:01 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E5FD233.4030103@oracle.com> References: <4E5FD233.4030103@oracle.com> Message-ID: <4E60C091.3010706@gmx.de> Sherman, IMHO, synchronizing multiple call site does NOT look good to me. On next chance, someone other calls lookup() without knowing, that it has to be synchronized. Please simply synchronize lookup() itself, maybe in sophisticated way (only the necessary part of the code). The same seems to count for init(). (don't know if synchronised would apply on abstract methods, but in any way on it's implementation): protected synchronized void init() {} -Ulf Am 01.09.2011 20:42, schrieb Xueming Shen: > Hi, > > This is a forward porting. Same fix has been in jdk5/6, and will be in jdk 7u2 later. > > http://cr.openjdk.java.net/~sherman/6898310/webrev > > The change itself is relative simple. And given its race-condition nature, no reliable > regression test case is provided. > > Thanks! > > -Sherman > From Ulf.Zibis at gmx.de Fri Sep 2 12:46:30 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Sep 2011 14:46:30 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60BF42.6050200@oracle.com> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> Message-ID: <4E60D026.4040707@gmx.de> Am 02.09.2011 13:34, schrieb Alan Bateman: > R?mi Forax wrote: >> >> Arghhh, next() can return null ! >> >> CharsetProvider provider = ... >> Iterator it = provider.charsets(); >> Iterator it2 = provider.charsets(); >> Charset charset = it.next(); >> provider.deleteCharset(charset.name(), ...) >> System.out.println(it2.next()); // print null >> >> even if I'm not sure a lot of CharsetProvider actually calls deleteCharset >> there is a possible bug here. >> There is another sync nit on lookups. See the comments on: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853689 > deleteCharset isn't a public method so I don't think this can happen. I don't disagree that that > the iterator code should be re-written, just thinking it's separate from fixing the race condition. Yes, and there are more reasons to rewrite the AbstractCharsetProvider: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850361 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862160 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862165 https://bugs.openjdk.java.net/show_bug.cgi?id=100098 Instead _recoding_ an iterator for method charsets() you could simply use Collections.unmodifiableSet().iterator(). See example (Line 141 vs. 62): https://bugs.openjdk.java.net/attachment.cgi?id=131&action=diff#a/src/share/classes/sun/nio/cs/FastCharsetProvider.java_sec2 For AbstractCharsetProvider (here renamed to ExternalCharsetProvider) See (Line 134): https://bugs.openjdk.java.net/attachment.cgi?id=131&action=diff#a/src/share/classes/sun/nio/cs/ExternalCharsetProvider.java_sec1 -Ulf From forax at univ-mlv.fr Fri Sep 2 13:00:38 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 02 Sep 2011 15:00:38 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60BF42.6050200@oracle.com> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> Message-ID: <4E60D376.6050304@univ-mlv.fr> On 09/02/2011 01:34 PM, Alan Bateman wrote: > R?mi Forax wrote: >> >> Arghhh, next() can return null ! >> >> CharsetProvider provider = ... >> Iterator it = provider.charsets(); >> Iterator it2 = provider.charsets(); >> Charset charset = it.next(); >> provider.deleteCharset(charset.name(), ...) >> System.out.println(it2.next()); // print null >> >> even if I'm not sure a lot of CharsetProvider actually calls >> deleteCharset >> there is a possible bug here. >> > deleteCharset isn't a public method so I don't think this can happen. I doesn't happen currently in the JDK because deleteCharset() (and charset()) are only called in ExtendedCharset.init(). > I don't disagree that that the iterator code should be re-written, > just thinking it's separate from fixing the race condition. A way to solve the problem is to split AbstractCharsetProvider in two objects i.e we should create a new object named CharsetProviderView that contains deleteCharset() and charset() and provide this object as parameter of init. The idea is that during the initialization (in init()) calling deleteCharset/charset is safe, not after. > > -Alan. > R?mi From Ulf.Zibis at gmx.de Fri Sep 2 13:17:08 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Sep 2011 15:17:08 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60D376.6050304@univ-mlv.fr> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> <4E60D376.6050304@univ-mlv.fr> Message-ID: <4E60D754.3060100@gmx.de> Am 02.09.2011 15:00, schrieb R?mi Forax: > > A way to solve the problem is to split AbstractCharsetProvider in two objects > i.e we should create a new object named CharsetProviderView that contains > deleteCharset() and charset() and provide this object as parameter of init. > > The idea is that during the initialization (in init()) calling deleteCharset/charset is safe, > not after. Calling deleteCharset/charset() from init() is completely superfluous. See my implementation********(Replacement of AbstractCharsetProvider) from *****Bug 100098* - Make sun.nio.cs.* charset objects light-weight**** : https://bugs.openjdk.java.net/attachment.cgi?id=131&action=diff#a/src/share/classes/sun/nio/cs/ExternalCharsetProvider.java_sec1 -Ulf From forax at univ-mlv.fr Fri Sep 2 13:40:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 02 Sep 2011 15:40:03 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60D754.3060100@gmx.de> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> <4E60D376.6050304@univ-mlv.fr> <4E60D754.3060100@gmx.de> Message-ID: <4E60DCB3.9080709@univ-mlv.fr> On 09/02/2011 03:17 PM, Ulf Zibis wrote: > Am 02.09.2011 15:00, schrieb R?mi Forax: >> >> A way to solve the problem is to split AbstractCharsetProvider in two >> objects >> i.e we should create a new object named CharsetProviderView that >> contains >> deleteCharset() and charset() and provide this object as parameter of >> init. >> >> The idea is that during the initialization (in init()) calling >> deleteCharset/charset is safe, >> not after. > > Calling deleteCharset/charset() from init() is completely superfluous. > See my implementation********(Replacement of AbstractCharsetProvider) from > *****Bug 100098* > - Make > sun.nio.cs.* charset objects light-weight**** : > https://bugs.openjdk.java.net/attachment.cgi?id=131&action=diff#a/src/share/classes/sun/nio/cs/ExternalCharsetProvider.java_sec1 > I agree, you can get ride of init(), but I would prefer to use a static block, instead of a properties file. > -Ulf > R?mi From Ulf.Zibis at gmx.de Fri Sep 2 13:52:46 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Sep 2011 15:52:46 +0200 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60DCB3.9080709@univ-mlv.fr> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> <4E60D376.6050304@univ-mlv.fr> <4E60D754.3060100@gmx.de> <4E60DCB3.9080709@univ-mlv.fr> Message-ID: <4E60DFAE.8000107@gmx.de> Am 02.09.2011 15:40, schrieb R?mi Forax: > On 09/02/2011 03:17 PM, Ulf Zibis wrote: >> Am 02.09.2011 15:00, schrieb R?mi Forax: >>> >>> A way to solve the problem is to split AbstractCharsetProvider in two objects >>> i.e we should create a new object named CharsetProviderView that contains >>> deleteCharset() and charset() and provide this object as parameter of init. >>> >>> The idea is that during the initialization (in init()) calling deleteCharset/charset is safe, >>> not after. >> >> Calling deleteCharset/charset() from init() is completely superfluous. Oops, deleteCharset/charset() is replaced by (un)register(), so same problem occurs. Soulution could be to block (un)register() to work, if isCustomized() of afterCustomization() returns true. -Ulf >> See my implementation********(Replacement of AbstractCharsetProvider) from >> *****Bug 100098* - Make sun.nio.cs.* >> charset objects light-weight**** : >> https://bugs.openjdk.java.net/attachment.cgi?id=131&action=diff#a/src/share/classes/sun/nio/cs/ExternalCharsetProvider.java_sec1 >> > > I agree, you can get ride of init(), but I would prefer to use a static block, > instead of a properties file. > >> -Ulf >> > > R?mi > From kumar.x.srinivasan at oracle.com Fri Sep 2 16:07:04 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 02 Sep 2011 16:07:04 +0000 Subject: hg: jdk8/tl/langtools: 7024096: Stack trace has invalid line numbers Message-ID: <20110902160710.3449C47313@hg.openjdk.java.net> Changeset: 02b8381781ab Author: ksrini Date: 2011-09-02 07:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/02b8381781ab 7024096: Stack trace has invalid line numbers Reviewed-by: jjg, darcy Contributed-by: bruce.chapman.nz at gmail.com ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/jvm/T7024096.java From xueming.shen at oracle.com Fri Sep 2 16:38:22 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 02 Sep 2011 09:38:22 -0700 Subject: Codereview request for 6898310: (cs) Charset cache lookups should be synchronized In-Reply-To: <4E60D376.6050304@univ-mlv.fr> References: <4E5FD233.4030103@oracle.com> <4E60B536.1070105@oracle.com> <4E60BB5A.1030700@univ-mlv.fr> <4E60BF42.6050200@oracle.com> <4E60D376.6050304@univ-mlv.fr> Message-ID: <4E61067E.2000605@oracle.com> On 09/02/2011 06:00 AM, R?mi Forax wrote: > On 09/02/2011 01:34 PM, Alan Bateman wrote: >> R?mi Forax wrote: >>> >>> Arghhh, next() can return null ! >>> >>> CharsetProvider provider = ... >>> Iterator it = provider.charsets(); >>> Iterator it2 = provider.charsets(); >>> Charset charset = it.next(); >>> provider.deleteCharset(charset.name(), ...) >>> System.out.println(it2.next()); // print null >>> >>> even if I'm not sure a lot of CharsetProvider actually calls >>> deleteCharset >>> there is a possible bug here. >>> >> deleteCharset isn't a public method so I don't think this can happen. > > I doesn't happen currently in the JDK because deleteCharset() (and > charset()) > are only called in ExtendedCharset.init(). deleteCharset() was added later to workaround an "unusual" request for some Japanese charsets, and the AbstractcharsetProvider was shared by the ext and standard charset provider back then, so the "hook" was added in. In normal case, the provider is really not supposed to add a bunch of charsets during the initialization and then oops, I would like to delete some of them. So deleteCharset() is really not supposed to be used by anyone else, look it as an ugly implementation detail. Given the standard charset no longer uses the AbstractCharsetProvider, it might be the time to consider to have a clean implementation for the extended charset provider in JDK8. Yes, this is on the jdk8 to-do list. -Sherman > >> I don't disagree that that the iterator code should be re-written, >> just thinking it's separate from fixing the race condition. > > A way to solve the problem is to split AbstractCharsetProvider in two > objects > i.e we should create a new object named CharsetProviderView that contains > deleteCharset() and charset() and provide this object as parameter of > init. > > The idea is that during the initialization (in init()) calling > deleteCharset/charset is safe, > not after. > >> >> -Alan. >> > > R?mi > From maurizio.cimadamore at oracle.com Fri Sep 2 16:39:29 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 02 Sep 2011 16:39:29 +0000 Subject: hg: jdk8/tl/langtools: 7086261: javac doesn't report error as expected, it only reports ClientCodeWrapper$DiagnosticSourceUnwrapper Message-ID: <20110902163932.453C847317@hg.openjdk.java.net> Changeset: ec27e5befa53 Author: mcimadamore Date: 2011-09-02 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec27e5befa53 7086261: javac doesn't report error as expected, it only reports ClientCodeWrapper$DiagnosticSourceUnwrapper Summary: Missing override for toString() in ClientCodeUnwrapper.DiagnosticSourceUnwrapper Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java + test/tools/javac/api/7086261/T7086261.java From xueming.shen at oracle.com Fri Sep 2 17:21:26 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 02 Sep 2011 17:21:26 +0000 Subject: hg: jdk8/tl/jdk: 6898310: (cs) Charset cache lookups should be synchronized Message-ID: <20110902172137.E30FF47319@hg.openjdk.java.net> Changeset: 812c6d4d6a58 Author: sherman Date: 2011-09-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/812c6d4d6a58 6898310: (cs) Charset cache lookups should be synchronized Summary: synchronize the lookup in iterator Reviewed-by: alanb ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java From joe.darcy at oracle.com Fri Sep 2 22:06:00 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Sep 2011 15:06:00 -0700 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() Message-ID: <4E615348.5060101@oracle.com> Hello. Please review this simple patch to replace explicit array copy loops with System.arraycopy: 6989067 BigInteger's array copiers should be converted to System.arraycopy() http://cr.openjdk.java.net/~darcy/6989067.0/ Patch below. Thanks, -Joe --- old/src/share/classes/java/math/BigInteger.java 2011-09-02 14:48:34.000000000 -0700 +++ new/src/share/classes/java/math/BigInteger.java 2011-09-02 14:48:34.000000000 -0700 @@ -1612,14 +1612,12 @@ } else { // Array must be resized if (nBits <= (32-bitsInHighWord)) { int result[] = new int[nInts+len]; - for (int i=0; i>> 5; int[] mag = new int[numInts]; - for (int i=0; i>> nBits; @@ -2561,7 +2553,7 @@ if (signum < 0) { // Check if magnitude is a power of two boolean pow2 = (Integer.bitCount(mag[0]) == 1); - for(int i=1; i< len && pow2; i++) + for (int i=1; i< len && pow2; i++) pow2 = (mag[i] == 0); n = (pow2 ? magBitLength -1 : magBitLength); From forax at univ-mlv.fr Fri Sep 2 22:30:44 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sat, 03 Sep 2011 00:30:44 +0200 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() In-Reply-To: <4E615348.5060101@oracle.com> References: <4E615348.5060101@oracle.com> Message-ID: <4E615914.70609@univ-mlv.fr> On 09/03/2011 12:06 AM, joe.darcy at oracle.com wrote: > Hello. > > Please review this simple patch to replace explicit array copy loops > with System.arraycopy: > > 6989067 BigInteger's array copiers should be converted to > System.arraycopy() > http://cr.openjdk.java.net/~darcy/6989067.0/ > > Patch below. > > Thanks, > > -Joe Hi Joe, for me, some occurence you can use Arrays.copyOf instead of System.arraycopy in order to avoid to fill (or partially fill part of) the array with zero. manual patch inlined below :) > > --- old/src/share/classes/java/math/BigInteger.java 2011-09-02 > 14:48:34.000000000 -0700 > +++ new/src/share/classes/java/math/BigInteger.java 2011-09-02 > 14:48:34.000000000 -0700 > @@ -1612,14 +1612,12 @@ > } else { // Array must be resized > if (nBits <= (32-bitsInHighWord)) { > int result[] = new int[nInts+len]; > - for (int i=0; i - result[i] = a[i]; > + System.arraycopy(a, 0, result, 0, len); > primitiveLeftShift(result, result.length, nBits); > return result; > } else { > int result[] = new int[nInts+len+1]; > - for (int i=0; i - result[i] = a[i]; > + System.arraycopy(a, 0, result, 0, len); > primitiveRightShift(result, result.length, 32 - nBits); > return result; > } > @@ -1908,8 +1906,7 @@ > > // Set t to high half of b > int[] t = new int[modLen]; > - for(int i=0; i - t[i] = b[i]; > + System.arraycopy(b, 0, t, 0, modLen); can be simplified to: int[] t = Array.copyOf(b, modLen); > > // Fill in the table with odd powers of the base > for (int i=1; i @@ -2006,14 +2003,12 @@ > > // Convert result out of Montgomery form and return > int[] t2 = new int[2*modLen]; > - for(int i=0; i - t2[i+modLen] = b[i]; > + System.arraycopy(b, 0, t2, modLen, modLen); > > b = montReduce(t2, mod, modLen, inv); > > t2 = new int[modLen]; > - for(int i=0; i - t2[i] = b[i]; > + System.arraycopy(b, 0, t2, 0, modLen); can be simplified to: t2 = Arrays.copyOf(b, modLen); > > return new BigInteger(1, t2); > } > @@ -2154,8 +2149,7 @@ > // Copy remaining ints of mag > int numInts = (p + 31) >>> 5; > int[] mag = new int[numInts]; > - for (int i=0; i - mag[i] = this.mag[i + (this.mag.length - numInts)]; > + System.arraycopy(this.mag, (this.mag.length - numInts), mag, > 0, numInts); > > // Mask out any excess bits > int excessBits = (numInts << 5) - p; > @@ -2221,7 +2215,7 @@ > return shiftRight(-n); > } > } > - int[] newMag = shiftLeft(mag,n); > + int[] newMag = shiftLeft(mag, n); > > return new BigInteger(newMag, signum); > } > @@ -2234,8 +2228,7 @@ > > if (nBits == 0) { > newMag = new int[magLen + nInts]; > - for (int i=0; i - newMag[i] = mag[i]; > + System.arraycopy(mag, 0, newMag, 0, magLen); newMag = Arrays.copyOf(magLen + nInts); > } else { > int i = 0; > int nBits2 = 32 - nBits; > @@ -2289,8 +2282,7 @@ > if (nBits == 0) { > int newMagLen = magLen - nInts; > newMag = new int[newMagLen]; > - for (int i=0; i - newMag[i] = mag[i]; > + System.arraycopy(mag, 0, newMag, 0, newMagLen); newMag = Arrays.copyOf(newMagLen); > } else { > int i = 0; > int highBits = mag[0] >>> nBits; > @@ -2561,7 +2553,7 @@ > if (signum < 0) { > // Check if magnitude is a power of two > boolean pow2 = (Integer.bitCount(mag[0]) == 1); > - for(int i=1; i< len && pow2; i++) > + for (int i=1; i< len && pow2; i++) > pow2 = (mag[i] == 0); > > n = (pow2 ? magBitLength -1 : magBitLength); > Also, this change can have a negative impact because as far as I know system.arraycopy/Arrays.copyOf uses a loop even if the number of iteration is really small. A for loop will be unrolled by the VM. regards, R?mi From joe.darcy at oracle.com Fri Sep 2 23:06:27 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Sep 2011 23:06:27 +0000 Subject: hg: jdk8/tl/jdk: 6989067: BigInteger's array copiers should be converted to System.arraycopy() Message-ID: <20110902230651.7DB8447327@hg.openjdk.java.net> Changeset: 95aff7cbf590 Author: darcy Date: 2011-09-02 16:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95aff7cbf590 6989067: BigInteger's array copiers should be converted to System.arraycopy() Reviewed-by: mduigou, forax ! src/share/classes/java/math/BigInteger.java From joe.darcy at oracle.com Fri Sep 2 23:19:03 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Sep 2011 16:19:03 -0700 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() In-Reply-To: <4E615914.70609@univ-mlv.fr> References: <4E615348.5060101@oracle.com> <4E615914.70609@univ-mlv.fr> Message-ID: <4E616467.5070905@oracle.com> Hi Remi. Modified as suggested to use Arrays.copyOf before being pushed. The performance team recommend to me this class of change be implemented so I assume (and hope) the VM properly handles small arrays in a performance sense. Thanks, -Joe On 9/2/2011 3:30 PM, R?mi Forax wrote: > On 09/03/2011 12:06 AM, joe.darcy at oracle.com wrote: >> Hello. >> >> Please review this simple patch to replace explicit array copy loops >> with System.arraycopy: >> >> 6989067 BigInteger's array copiers should be converted to >> System.arraycopy() >> http://cr.openjdk.java.net/~darcy/6989067.0/ >> >> Patch below. >> >> Thanks, >> >> -Joe > > Hi Joe, > for me, some occurence you can use Arrays.copyOf instead of > System.arraycopy > in order to avoid to fill (or partially fill part of) the array with > zero. > > manual patch inlined below :) > >> >> --- old/src/share/classes/java/math/BigInteger.java 2011-09-02 >> 14:48:34.000000000 -0700 >> +++ new/src/share/classes/java/math/BigInteger.java 2011-09-02 >> 14:48:34.000000000 -0700 >> @@ -1612,14 +1612,12 @@ >> } else { // Array must be resized >> if (nBits <= (32-bitsInHighWord)) { >> int result[] = new int[nInts+len]; >> - for (int i=0; i> - result[i] = a[i]; >> + System.arraycopy(a, 0, result, 0, len); >> primitiveLeftShift(result, result.length, nBits); >> return result; >> } else { >> int result[] = new int[nInts+len+1]; >> - for (int i=0; i> - result[i] = a[i]; >> + System.arraycopy(a, 0, result, 0, len); >> primitiveRightShift(result, result.length, 32 - nBits); >> return result; >> } >> @@ -1908,8 +1906,7 @@ >> >> // Set t to high half of b >> int[] t = new int[modLen]; >> - for(int i=0; i> - t[i] = b[i]; >> + System.arraycopy(b, 0, t, 0, modLen); > > can be simplified to: > int[] t = Array.copyOf(b, modLen); > >> >> // Fill in the table with odd powers of the base >> for (int i=1; i> @@ -2006,14 +2003,12 @@ >> >> // Convert result out of Montgomery form and return >> int[] t2 = new int[2*modLen]; >> - for(int i=0; i> - t2[i+modLen] = b[i]; >> + System.arraycopy(b, 0, t2, modLen, modLen); >> >> b = montReduce(t2, mod, modLen, inv); >> >> t2 = new int[modLen]; >> - for(int i=0; i> - t2[i] = b[i]; >> + System.arraycopy(b, 0, t2, 0, modLen); > > can be simplified to: > t2 = Arrays.copyOf(b, modLen); > >> >> return new BigInteger(1, t2); >> } >> @@ -2154,8 +2149,7 @@ >> // Copy remaining ints of mag >> int numInts = (p + 31) >>> 5; >> int[] mag = new int[numInts]; >> - for (int i=0; i> - mag[i] = this.mag[i + (this.mag.length - numInts)]; >> + System.arraycopy(this.mag, (this.mag.length - numInts), mag, >> 0, numInts); >> >> // Mask out any excess bits >> int excessBits = (numInts << 5) - p; >> @@ -2221,7 +2215,7 @@ >> return shiftRight(-n); >> } >> } >> - int[] newMag = shiftLeft(mag,n); >> + int[] newMag = shiftLeft(mag, n); >> >> return new BigInteger(newMag, signum); >> } >> @@ -2234,8 +2228,7 @@ >> >> if (nBits == 0) { >> newMag = new int[magLen + nInts]; >> - for (int i=0; i> - newMag[i] = mag[i]; >> + System.arraycopy(mag, 0, newMag, 0, magLen); > > newMag = Arrays.copyOf(magLen + nInts); > >> } else { >> int i = 0; >> int nBits2 = 32 - nBits; >> @@ -2289,8 +2282,7 @@ >> if (nBits == 0) { >> int newMagLen = magLen - nInts; >> newMag = new int[newMagLen]; >> - for (int i=0; i> - newMag[i] = mag[i]; >> + System.arraycopy(mag, 0, newMag, 0, newMagLen); > > newMag = Arrays.copyOf(newMagLen); > >> } else { >> int i = 0; >> int highBits = mag[0] >>> nBits; >> @@ -2561,7 +2553,7 @@ >> if (signum < 0) { >> // Check if magnitude is a power of two >> boolean pow2 = (Integer.bitCount(mag[0]) == 1); >> - for(int i=1; i< len && pow2; i++) >> + for (int i=1; i< len && pow2; i++) >> pow2 = (mag[i] == 0); >> >> n = (pow2 ? magBitLength -1 : magBitLength); >> > > Also, this change can have a negative impact because as far as I know > system.arraycopy/Arrays.copyOf uses a loop even if the number of > iteration > is really small. A for loop will be unrolled by the VM. > > regards, > R?mi > > > From forax at univ-mlv.fr Fri Sep 2 23:25:29 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sat, 03 Sep 2011 01:25:29 +0200 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() In-Reply-To: <4E616467.5070905@oracle.com> References: <4E615348.5060101@oracle.com> <4E615914.70609@univ-mlv.fr> <4E616467.5070905@oracle.com> Message-ID: <4E6165E9.5000606@univ-mlv.fr> On 09/03/2011 01:19 AM, joe.darcy at oracle.com wrote: > Hi Remi. > > Modified as suggested to use Arrays.copyOf before being pushed. > > The performance team recommend to me this class of change be > implemented so I assume (and hope) the VM properly handles small > arrays in a performance sense. good to know :) > > Thanks, > > -Joe cheers, R?mi > > On 9/2/2011 3:30 PM, R?mi Forax wrote: >> On 09/03/2011 12:06 AM, joe.darcy at oracle.com wrote: >>> Hello. >>> >>> Please review this simple patch to replace explicit array copy loops >>> with System.arraycopy: >>> >>> 6989067 BigInteger's array copiers should be converted to >>> System.arraycopy() >>> http://cr.openjdk.java.net/~darcy/6989067.0/ >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >> >> Hi Joe, >> for me, some occurence you can use Arrays.copyOf instead of >> System.arraycopy >> in order to avoid to fill (or partially fill part of) the array with >> zero. >> >> manual patch inlined below :) >> >>> >>> --- old/src/share/classes/java/math/BigInteger.java 2011-09-02 >>> 14:48:34.000000000 -0700 >>> +++ new/src/share/classes/java/math/BigInteger.java 2011-09-02 >>> 14:48:34.000000000 -0700 >>> @@ -1612,14 +1612,12 @@ >>> } else { // Array must be resized >>> if (nBits <= (32-bitsInHighWord)) { >>> int result[] = new int[nInts+len]; >>> - for (int i=0; i>> - result[i] = a[i]; >>> + System.arraycopy(a, 0, result, 0, len); >>> primitiveLeftShift(result, result.length, nBits); >>> return result; >>> } else { >>> int result[] = new int[nInts+len+1]; >>> - for (int i=0; i>> - result[i] = a[i]; >>> + System.arraycopy(a, 0, result, 0, len); >>> primitiveRightShift(result, result.length, 32 - nBits); >>> return result; >>> } >>> @@ -1908,8 +1906,7 @@ >>> >>> // Set t to high half of b >>> int[] t = new int[modLen]; >>> - for(int i=0; i>> - t[i] = b[i]; >>> + System.arraycopy(b, 0, t, 0, modLen); >> >> can be simplified to: >> int[] t = Array.copyOf(b, modLen); >> >>> >>> // Fill in the table with odd powers of the base >>> for (int i=1; i>> @@ -2006,14 +2003,12 @@ >>> >>> // Convert result out of Montgomery form and return >>> int[] t2 = new int[2*modLen]; >>> - for(int i=0; i>> - t2[i+modLen] = b[i]; >>> + System.arraycopy(b, 0, t2, modLen, modLen); >>> >>> b = montReduce(t2, mod, modLen, inv); >>> >>> t2 = new int[modLen]; >>> - for(int i=0; i>> - t2[i] = b[i]; >>> + System.arraycopy(b, 0, t2, 0, modLen); >> >> can be simplified to: >> t2 = Arrays.copyOf(b, modLen); >> >>> >>> return new BigInteger(1, t2); >>> } >>> @@ -2154,8 +2149,7 @@ >>> // Copy remaining ints of mag >>> int numInts = (p + 31) >>> 5; >>> int[] mag = new int[numInts]; >>> - for (int i=0; i>> - mag[i] = this.mag[i + (this.mag.length - numInts)]; >>> + System.arraycopy(this.mag, (this.mag.length - numInts), >>> mag, 0, numInts); >>> >>> // Mask out any excess bits >>> int excessBits = (numInts << 5) - p; >>> @@ -2221,7 +2215,7 @@ >>> return shiftRight(-n); >>> } >>> } >>> - int[] newMag = shiftLeft(mag,n); >>> + int[] newMag = shiftLeft(mag, n); >>> >>> return new BigInteger(newMag, signum); >>> } >>> @@ -2234,8 +2228,7 @@ >>> >>> if (nBits == 0) { >>> newMag = new int[magLen + nInts]; >>> - for (int i=0; i>> - newMag[i] = mag[i]; >>> + System.arraycopy(mag, 0, newMag, 0, magLen); >> >> newMag = Arrays.copyOf(magLen + nInts); >> >>> } else { >>> int i = 0; >>> int nBits2 = 32 - nBits; >>> @@ -2289,8 +2282,7 @@ >>> if (nBits == 0) { >>> int newMagLen = magLen - nInts; >>> newMag = new int[newMagLen]; >>> - for (int i=0; i>> - newMag[i] = mag[i]; >>> + System.arraycopy(mag, 0, newMag, 0, newMagLen); >> >> newMag = Arrays.copyOf(newMagLen); >> >>> } else { >>> int i = 0; >>> int highBits = mag[0] >>> nBits; >>> @@ -2561,7 +2553,7 @@ >>> if (signum < 0) { >>> // Check if magnitude is a power of two >>> boolean pow2 = (Integer.bitCount(mag[0]) == 1); >>> - for(int i=1; i< len && pow2; i++) >>> + for (int i=1; i< len && pow2; i++) >>> pow2 = (mag[i] == 0); >>> >>> n = (pow2 ? magBitLength -1 : magBitLength); >>> >> >> Also, this change can have a negative impact because as far as I know >> system.arraycopy/Arrays.copyOf uses a loop even if the number of >> iteration >> is really small. A for loop will be unrolled by the VM. >> >> regards, >> R?mi >> >> >> From joe.darcy at oracle.com Sat Sep 3 00:44:59 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Sep 2011 17:44:59 -0700 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger Message-ID: <4E61788B.2060402@oracle.com> Hello. Please review this change to only instantiated an Unsafe object in BigInteger and BigDecimal if serialization is done: 6838776 Defer initialization of static fields in java.math.BigInteger http://cr.openjdk.java.net/~darcy/6838776.0/ Thanks, -Joe From joe.darcy at oracle.com Sat Sep 3 00:44:15 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 02 Sep 2011 17:44:15 -0700 Subject: Are the faster versions of HashMap and BigInteger going into jdk7? In-Reply-To: <4E48DB4E.2060401@mindspring.com> References: <212322090910230801k518cb2cew36cb50fa96c0723e@mail.gmail.com> <17c6771e0910230812g771347d8gcf2d55045e9f6460@mail.gmail.com> <212322090910230907u326420ccte673af409e5e24c5@mail.gmail.com> <17c6771e0910231001g9fcd67bt489309dfeec60016@mail.gmail.com> <4AE69D6D.7010500@mindspring.com> <4E48DB4E.2060401@mindspring.com> Message-ID: <4E61785F.2020501@oracle.com> Alan Eliasen wrote: > On 10/27/2009 01:12 AM, Alan Eliasen wrote: > >> On 10/23/2009 11:01 AM, Andrew John Hughes wrote: >> >>> 6622432 is the one of the ones I just pointed to i.e. it's in JDK7. >>> If Alan has a further patch and hasn't even submitted it for >>> inclusion, it's obviously not in. >>> >> I had just queried Joe Darcy at Sun about reviewing my patches for >> Karatsuba and Toom-Cook multiplication in BigInteger again last week. >> His reply was: >> >> "Yes, I apologize again for the repeated delays; I want to get your >> Karatsuba work reviewed and integrated within this JDK 7 milestone (the >> next few weeks)." >> > > How's this going? (2 years later.) > > Still going! Sorry again for the repeated and long delays; the last two years have been eventful in other areas. As you may have seen, I've just recently pushed a large changeset primarily addressing performance tuning in BigDecimal [1]. With some other large reviews I have oustanding and JavaOne, etc., I think I should be able to have your BigInteger patches integrated into JDK 8 by the end of the year. After the changes are in JDK 8, it is possible for them to be backported to the JDK 7 update train. Thanks, -Joe [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffada2ce20e5 From mike.duigou at oracle.com Sat Sep 3 01:26:59 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 2 Sep 2011 18:26:59 -0700 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: <4E61788B.2060402@oracle.com> References: <4E61788B.2060402@oracle.com> Message-ID: Looks good. Nice little performance tweak. You may want to use ExceptionInInitializerError rather than plain Error. Mike On Sep 2 2011, at 17:44 , joe.darcy at oracle.com wrote: > Hello. > > Please review this change to only instantiated an Unsafe object in BigInteger and BigDecimal if serialization is done: > > 6838776 Defer initialization of static fields in java.math.BigInteger > http://cr.openjdk.java.net/~darcy/6838776.0/ > > Thanks, > > -Joe From chris.hegarty at oracle.com Sat Sep 3 06:47:23 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 03 Sep 2011 06:47:23 +0000 Subject: hg: jdk8/tl/jdk: 7084032: test/java/net/Inet6Address/B6558853.java fails on Windows XP/2003 if IPv6 Message-ID: <20110903064744.9FFBA4733B@hg.openjdk.java.net> Changeset: 5b8f8397379f Author: chegar Date: 2011-09-03 07:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b8f8397379f 7084032: test/java/net/Inet6Address/B6558853.java fails on Windows XP/2003 if IPv6 Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c From sebastian.sickelmann at gmx.de Sat Sep 3 07:11:32 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 03 Sep 2011 09:11:32 +0200 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: <4E61788B.2060402@oracle.com> References: <4E61788B.2060402@oracle.com> Message-ID: <4E61D324.9080504@gmx.de> Looks good to me. Nice pattern to use static initialization on first usage of UnsafeHolder instead of using lazy initialization code with double-check-ideom for synchronizing in the two accessing methods. It should works for all vm i have workes with (sun/oracle,ibm) , but is it garanted by vm spec that it is not initialized while initializing Big{Integer,Decimal}? -- Sebastian Am 03.09.2011 02:44, schrieb joe.darcy at oracle.com: > Hello. > > Please review this change to only instantiated an Unsafe object in > BigInteger and BigDecimal if serialization is done: > > 6838776 Defer initialization of static fields in java.math.BigInteger > http://cr.openjdk.java.net/~darcy/6838776.0/ > > Thanks, > > -Joe From David.Holmes at oracle.com Sat Sep 3 09:02:32 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 03 Sep 2011 19:02:32 +1000 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() In-Reply-To: <4E616467.5070905@oracle.com> References: <4E615348.5060101@oracle.com> <4E615914.70609@univ-mlv.fr> <4E616467.5070905@oracle.com> Message-ID: <4E61ED28.80005@oracle.com> On 3/09/2011 9:19 AM, joe.darcy at oracle.com wrote: > Modified as suggested to use Arrays.copyOf before being pushed. > > The performance team recommend to me this class of change be implemented so > I assume (and hope) the VM properly handles small arrays in a performance > sense. I was going to ask about performance here. Of course we should be using arraycopy and copyOf et al and if there are performance issues they should be fixed in those libraries, but in reality ... I assume we have some performance benchmarks for BigInteger? David > Thanks, > > -Joe > > On 9/2/2011 3:30 PM, R?mi Forax wrote: >> On 09/03/2011 12:06 AM, joe.darcy at oracle.com wrote: >>> Hello. >>> >>> Please review this simple patch to replace explicit array copy loops with >>> System.arraycopy: >>> >>> 6989067 BigInteger's array copiers should be converted to System.arraycopy() >>> http://cr.openjdk.java.net/~darcy/6989067.0/ >>> >>> Patch below. >>> >>> Thanks, >>> >>> -Joe >> >> Hi Joe, >> for me, some occurence you can use Arrays.copyOf instead of System.arraycopy >> in order to avoid to fill (or partially fill part of) the array with zero. >> >> manual patch inlined below :) >> >>> >>> --- old/src/share/classes/java/math/BigInteger.java 2011-09-02 >>> 14:48:34.000000000 -0700 >>> +++ new/src/share/classes/java/math/BigInteger.java 2011-09-02 >>> 14:48:34.000000000 -0700 >>> @@ -1612,14 +1612,12 @@ >>> } else { // Array must be resized >>> if (nBits <= (32-bitsInHighWord)) { >>> int result[] = new int[nInts+len]; >>> - for (int i=0; i>> - result[i] = a[i]; >>> + System.arraycopy(a, 0, result, 0, len); >>> primitiveLeftShift(result, result.length, nBits); >>> return result; >>> } else { >>> int result[] = new int[nInts+len+1]; >>> - for (int i=0; i>> - result[i] = a[i]; >>> + System.arraycopy(a, 0, result, 0, len); >>> primitiveRightShift(result, result.length, 32 - nBits); >>> return result; >>> } >>> @@ -1908,8 +1906,7 @@ >>> >>> // Set t to high half of b >>> int[] t = new int[modLen]; >>> - for(int i=0; i>> - t[i] = b[i]; >>> + System.arraycopy(b, 0, t, 0, modLen); >> >> can be simplified to: >> int[] t = Array.copyOf(b, modLen); >> >>> >>> // Fill in the table with odd powers of the base >>> for (int i=1; i>> @@ -2006,14 +2003,12 @@ >>> >>> // Convert result out of Montgomery form and return >>> int[] t2 = new int[2*modLen]; >>> - for(int i=0; i>> - t2[i+modLen] = b[i]; >>> + System.arraycopy(b, 0, t2, modLen, modLen); >>> >>> b = montReduce(t2, mod, modLen, inv); >>> >>> t2 = new int[modLen]; >>> - for(int i=0; i>> - t2[i] = b[i]; >>> + System.arraycopy(b, 0, t2, 0, modLen); >> >> can be simplified to: >> t2 = Arrays.copyOf(b, modLen); >> >>> >>> return new BigInteger(1, t2); >>> } >>> @@ -2154,8 +2149,7 @@ >>> // Copy remaining ints of mag >>> int numInts = (p + 31) >>> 5; >>> int[] mag = new int[numInts]; >>> - for (int i=0; i>> - mag[i] = this.mag[i + (this.mag.length - numInts)]; >>> + System.arraycopy(this.mag, (this.mag.length - numInts), mag, 0, numInts); >>> >>> // Mask out any excess bits >>> int excessBits = (numInts << 5) - p; >>> @@ -2221,7 +2215,7 @@ >>> return shiftRight(-n); >>> } >>> } >>> - int[] newMag = shiftLeft(mag,n); >>> + int[] newMag = shiftLeft(mag, n); >>> >>> return new BigInteger(newMag, signum); >>> } >>> @@ -2234,8 +2228,7 @@ >>> >>> if (nBits == 0) { >>> newMag = new int[magLen + nInts]; >>> - for (int i=0; i>> - newMag[i] = mag[i]; >>> + System.arraycopy(mag, 0, newMag, 0, magLen); >> >> newMag = Arrays.copyOf(magLen + nInts); >> >>> } else { >>> int i = 0; >>> int nBits2 = 32 - nBits; >>> @@ -2289,8 +2282,7 @@ >>> if (nBits == 0) { >>> int newMagLen = magLen - nInts; >>> newMag = new int[newMagLen]; >>> - for (int i=0; i>> - newMag[i] = mag[i]; >>> + System.arraycopy(mag, 0, newMag, 0, newMagLen); >> >> newMag = Arrays.copyOf(newMagLen); >> >>> } else { >>> int i = 0; >>> int highBits = mag[0] >>> nBits; >>> @@ -2561,7 +2553,7 @@ >>> if (signum < 0) { >>> // Check if magnitude is a power of two >>> boolean pow2 = (Integer.bitCount(mag[0]) == 1); >>> - for(int i=1; i< len && pow2; i++) >>> + for (int i=1; i< len && pow2; i++) >>> pow2 = (mag[i] == 0); >>> >>> n = (pow2 ? magBitLength -1 : magBitLength); >>> >> >> Also, this change can have a negative impact because as far as I know >> system.arraycopy/Arrays.copyOf uses a loop even if the number of iteration >> is really small. A for loop will be unrolled by the VM. >> >> regards, >> R?mi >> >> >> From David.Holmes at oracle.com Sat Sep 3 09:09:08 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 03 Sep 2011 19:09:08 +1000 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: <4E61D324.9080504@gmx.de> References: <4E61788B.2060402@oracle.com> <4E61D324.9080504@gmx.de> Message-ID: <4E61EEB4.8060603@oracle.com> On 3/09/2011 5:11 PM, Sebastian Sickelmann wrote: > Looks good to me. > Nice pattern to use static initialization on first usage of UnsafeHolder > instead of using lazy initialization code with double-check-ideom for > synchronizing in the two accessing methods. It should works for all vm i > have workes with (sun/oracle,ibm) , but is it garanted by vm spec that it is > not initialized while initializing Big{Integer,Decimal}? If I understand your question correctly, class initialization is precisely defined as to when it can and must occur. While the VM has some latitude in loading and linking, initialization can only occur when certain actions take place (JVMS 5.5). David > -- Sebastian > > Am 03.09.2011 02:44, schrieb joe.darcy at oracle.com: >> Hello. >> >> Please review this change to only instantiated an Unsafe object in >> BigInteger and BigDecimal if serialization is done: >> >> 6838776 Defer initialization of static fields in java.math.BigInteger >> http://cr.openjdk.java.net/~darcy/6838776.0/ >> >> Thanks, >> >> -Joe > From forax at univ-mlv.fr Sat Sep 3 14:37:06 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 03 Sep 2011 16:37:06 +0200 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: References: <4E61788B.2060402@oracle.com> Message-ID: <4E623B92.8030406@univ-mlv.fr> On 09/03/2011 03:26 AM, Mike Duigou wrote: > Looks good. Nice little performance tweak. > > You may want to use ExceptionInInitializerError rather than plain Error. > > Mike Mike, in that case you will get two ExceptionInInitializerError ? Joe, about the patch, I think the two methods in the holder should not be private (but package visible) to avoid the generation of accessor methods by the compiler. Otherwise, looks good. R?mi > > On Sep 2 2011, at 17:44 , joe.darcy at oracle.com wrote: > >> Hello. >> >> Please review this change to only instantiated an Unsafe object in BigInteger and BigDecimal if serialization is done: >> >> 6838776 Defer initialization of static fields in java.math.BigInteger >> http://cr.openjdk.java.net/~darcy/6838776.0/ >> >> Thanks, >> >> -Joe From joe.darcy at oracle.com Sat Sep 3 17:25:49 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 03 Sep 2011 10:25:49 -0700 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: References: <4E61788B.2060402@oracle.com> Message-ID: <4E62631D.70103@oracle.com> Mike Duigou wrote: > Looks good. Nice little performance tweak. > > You may want to use ExceptionInInitializerError rather than plain Error. > Yes; the more precise exception is better. I've also moved the initialization of unsafe into the try block; updated webrev: http://cr.openjdk.java.net/~darcy/6838776.1/ Thanks, -Joe > Mike > > On Sep 2 2011, at 17:44 , joe.darcy at oracle.com wrote: > > >> Hello. >> >> Please review this change to only instantiated an Unsafe object in BigInteger and BigDecimal if serialization is done: >> >> 6838776 Defer initialization of static fields in java.math.BigInteger >> http://cr.openjdk.java.net/~darcy/6838776.0/ >> >> Thanks, >> >> -Joe >> > > From joe.darcy at oracle.com Sat Sep 3 17:45:15 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 03 Sep 2011 10:45:15 -0700 Subject: JDK 8 core review request for 6989067 BigInteger's array copiers should be converted to System.arraycopy() In-Reply-To: <4E61ED28.80005@oracle.com> References: <4E615348.5060101@oracle.com> <4E615914.70609@univ-mlv.fr> <4E616467.5070905@oracle.com> <4E61ED28.80005@oracle.com> Message-ID: <4E6267AB.900@oracle.com> David Holmes wrote: > On 3/09/2011 9:19 AM, joe.darcy at oracle.com wrote: >> Modified as suggested to use Arrays.copyOf before being pushed. >> >> The performance team recommend to me this class of change be >> implemented so >> I assume (and hope) the VM properly handles small arrays in a >> performance >> sense. > > I was going to ask about performance here. Of course we should be > using arraycopy and copyOf et al and if there are performance issues > they should be fixed in those libraries, but in reality ... > > I assume we have some performance benchmarks for BigInteger? > The SPECJBB benchmarks involved BigDecimal, which in turn uses BigInteger (some of the time). In any case, I think the revised code is clearer than the explicit loops. -Joe From weijun.wang at oracle.com Mon Sep 5 03:23:55 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 05 Sep 2011 03:23:55 +0000 Subject: hg: jdk8/tl/jdk: 7081783: jarsigner error when no $HOME/.keystore Message-ID: <20110905032413.579704739A@hg.openjdk.java.net> Changeset: 62c25e4c30a3 Author: weijun Date: 2011-09-05 11:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62c25e4c30a3 7081783: jarsigner error when no $HOME/.keystore Reviewed-by: xuelei ! src/share/classes/sun/security/tools/JarSigner.java From weijun.wang at oracle.com Mon Sep 5 10:18:48 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 05 Sep 2011 10:18:48 +0000 Subject: hg: jdk8/tl/jdk: 7081411: DSA keypair generation affected by Solaris bug Message-ID: <20110905101914.0C6F6473A9@hg.openjdk.java.net> Changeset: 1d247911e035 Author: weijun Date: 2011-09-05 18:17 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d247911e035 7081411: DSA keypair generation affected by Solaris bug Reviewed-by: xuelei, mullan, alanb ! test/ProblemList.txt + test/java/security/KeyPairGenerator/SolarisShortDSA.java From sean.coffey at oracle.com Mon Sep 5 10:29:17 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Mon, 05 Sep 2011 10:29:17 +0000 Subject: hg: jdk8/tl/jdk: 7049079: NTSYSTEM CLASS IS LEAKING WINDOWS TOKENS Message-ID: <20110905102929.38473473AA@hg.openjdk.java.net> Changeset: 946e3b786d2d Author: coffeys Date: 2011-09-05 11:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/946e3b786d2d 7049079: NTSYSTEM CLASS IS LEAKING WINDOWS TOKENS Reviewed-by: weijun ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/windows/native/com/sun/security/auth/module/nt.c From joe.darcy at oracle.com Mon Sep 5 15:04:19 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 05 Sep 2011 15:04:19 +0000 Subject: hg: jdk8/tl/jdk: 7086710: java/util/Formatter/Basic.java failing after 7082971 Message-ID: <20110905150431.29093473B7@hg.openjdk.java.net> Changeset: 43880d125b79 Author: darcy Date: 2011-09-05 08:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43880d125b79 7086710: java/util/Formatter/Basic.java failing after 7082971 Reviewed-by: alanb ! src/share/classes/java/math/BigDecimal.java From joe.darcy at oracle.com Tue Sep 6 13:18:21 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Sep 2011 13:18:21 +0000 Subject: hg: jdk8/tl/jdk: 6838776: Defer initialization of static fields in java.math.BigInteger Message-ID: <20110906131844.44717473EA@hg.openjdk.java.net> Changeset: 5077e7a68259 Author: darcy Date: 2011-09-06 06:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5077e7a68259 6838776: Defer initialization of static fields in java.math.BigInteger Reviewed-by: mduigou, mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java From joe.darcy at oracle.com Tue Sep 6 13:20:03 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Sep 2011 06:20:03 -0700 Subject: JDK 8 code review request for 6838776 Defer initialization of static fields in java.math.BigInteger In-Reply-To: <4E623B92.8030406@univ-mlv.fr> References: <4E61788B.2060402@oracle.com> <4E623B92.8030406@univ-mlv.fr> Message-ID: <4E661E03.6040406@oracle.com> R?mi Forax wrote: > On 09/03/2011 03:26 AM, Mike Duigou wrote: >> Looks good. Nice little performance tweak. >> >> You may want to use ExceptionInInitializerError rather than plain Error. >> >> Mike > > Mike, > in that case you will get two ExceptionInInitializerError ? > > Joe, about the patch, I think the two methods in the holder should > not be private (but package visible) to avoid the generation of > accessor methods > by the compiler. Pushed without the private modifiers. Thanks for the suggestion, -Joe > > Otherwise, looks good. > > R?mi > >> >> On Sep 2 2011, at 17:44 , joe.darcy at oracle.com wrote: >> >>> Hello. >>> >>> Please review this change to only instantiated an Unsafe object in >>> BigInteger and BigDecimal if serialization is done: >>> >>> 6838776 Defer initialization of static fields in >>> java.math.BigInteger >>> http://cr.openjdk.java.net/~darcy/6838776.0/ >>> >>> Thanks, >>> >>> -Joe > From joe.darcy at oracle.com Tue Sep 6 13:54:50 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Sep 2011 06:54:50 -0700 Subject: hg: jdk8/tl/jdk: 6838776: Defer initialization of static fields in java.math.BigInteger In-Reply-To: <20110906131844.44717473EA@hg.openjdk.java.net> References: <20110906131844.44717473EA@hg.openjdk.java.net> Message-ID: <4E66262A.2010003@oracle.com> Oops! Should have listed Remi as the second reviewer. Sorry, -Joe joe.darcy at oracle.com wrote: > Changeset: 5077e7a68259 > Author: darcy > Date: 2011-09-06 06:17 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5077e7a68259 > > 6838776: Defer initialization of static fields in java.math.BigInteger > Reviewed-by: mduigou, mduigou > > ! src/share/classes/java/math/BigDecimal.java > ! src/share/classes/java/math/BigInteger.java > > From forax at univ-mlv.fr Tue Sep 6 14:30:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 06 Sep 2011 16:30:56 +0200 Subject: hg: jdk8/tl/jdk: 6838776: Defer initialization of static fields in java.math.BigInteger In-Reply-To: <4E66262A.2010003@oracle.com> References: <20110906131844.44717473EA@hg.openjdk.java.net> <4E66262A.2010003@oracle.com> Message-ID: <4E662EA0.3030300@univ-mlv.fr> On 09/06/2011 03:54 PM, Joe Darcy wrote: > Oops! Should have listed Remi as the second reviewer. > > Sorry, :) > > -Joe R?mi > > joe.darcy at oracle.com wrote: >> Changeset: 5077e7a68259 >> Author: darcy >> Date: 2011-09-06 06:17 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5077e7a68259 >> >> 6838776: Defer initialization of static fields in java.math.BigInteger >> Reviewed-by: mduigou, mduigou >> >> ! src/share/classes/java/math/BigDecimal.java >> ! src/share/classes/java/math/BigInteger.java >> > From weijun.wang at oracle.com Tue Sep 6 15:12:40 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 06 Sep 2011 23:12:40 +0800 Subject: code review request: 7087428: move client tests out of jdk_misc Message-ID: <4E663868.8040606@oracle.com> Hi Kelly Webrev at http://cr.openjdk.java.net/~weijun/7087428/webrev.00/ Basically I'd like jdk_misc batch to contain only "headless" tests and move all the others into their own batch. Changes: 1. Move javax/imageio, javax/print, sun/pisces to jdk_awt 2. Move com/sun/java/swing to jdk_swing 3. Move com/sun/org/apache/xml/internal/security to jdk_security3 4. Create a separate batch jdk_sound for javax/sound 5. Divide demo to different parts and move demo/jfc to jdk_swing. If the demo dir is moved to some other directory later, more updates will be needed. Please note that I change com/sun/java to com/sun/java/swing, and com/sun/org to com/sun/org/apache/xml/internal/security, since those are the only sub-dir there. There might be other sub-dirs later. Thanks Max -------- Original Message -------- 7087428: move client tests out of jdk_misc === *Description* ============================================================ The jdk_misc batch in test/Makefile contains tests for swing, sound etc, They should be moved to their own batches. From y.s.ramakrishna at oracle.com Tue Sep 6 17:27:37 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 06 Sep 2011 10:27:37 -0700 Subject: [Fwd: request for review (M): 4965777 GC changes to support use of discovered field for pending references] Message-ID: <4E665809.9090904@oracle.com> [Resent, as the original is still awaiting moderator approval -- i was not a member when the attached email was sent. Please include hotspot-gc-dev at openjdk.java.net in your responses, and visit the archives of that email list for emails related to this thread. Thanks -- ramki.] -------------- next part -------------- An embedded message was scrubbed... From: Ramki Ramakrishna Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references Date: Mon, 05 Sep 2011 02:16:18 -0700 Size: 4355 URL: From kelly.ohair at oracle.com Tue Sep 6 18:30:15 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 6 Sep 2011 11:30:15 -0700 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: <4E663868.8040606@oracle.com> References: <4E663868.8040606@oracle.com> Message-ID: Looks fine. But the files make/jprt.properties in both the root repository and the jdk repository will minor changes to add jdk_sound as a new test for JPRT. You can place it in the jprt.make.rule.all.test.targets list. -kto On Sep 6, 2011, at 8:12 AM, Weijun Wang wrote: > Hi Kelly > > Webrev at http://cr.openjdk.java.net/~weijun/7087428/webrev.00/ > > Basically I'd like jdk_misc batch to contain only "headless" tests and move all the others into their own batch. > > Changes: > > 1. Move javax/imageio, javax/print, sun/pisces to jdk_awt > 2. Move com/sun/java/swing to jdk_swing > 3. Move com/sun/org/apache/xml/internal/security to jdk_security3 > 4. Create a separate batch jdk_sound for javax/sound > 5. Divide demo to different parts and move demo/jfc to jdk_swing. If the demo dir is moved to some other directory later, more updates will be needed. > > Please note that I change com/sun/java to com/sun/java/swing, and com/sun/org to com/sun/org/apache/xml/internal/security, since those are the only sub-dir there. There might be other sub-dirs later. > > Thanks > Max > > -------- Original Message -------- > 7087428: move client tests out of jdk_misc > > === *Description* ============================================================ > The jdk_misc batch in test/Makefile contains tests for swing, sound etc, They should be moved to their own batches. > From y.s.ramakrishna at oracle.com Tue Sep 6 18:45:35 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 06 Sep 2011 11:45:35 -0700 Subject: [Fwd: request for review (M): 4965777 GC changes to support use of discovered field for pending references] In-Reply-To: <4E665809.9090904@oracle.com> References: <4E665809.9090904@oracle.com> Message-ID: <4E666A4F.4050502@oracle.com> Just so that there is no confusion. These changes by themselves are not intended to fix 4243978 and 4268317. They just fix 4965777 -- that is make GC and the ReferenceHandler thread use the discovered field for linking the elements of the pending list. I am assuming that 4243978 and 4268317 may need some more changes, but those are beyond the scope of this review request. -- ramki On 09/06/11 10:27, Y. S. Ramakrishna wrote: > > [Resent, as the original is still awaiting moderator approval -- i was > not a member > when the attached email was sent. Please include > hotspot-gc-dev at openjdk.java.net in > your responses, and visit the archives of that email list for emails > related to > this thread. Thanks -- ramki.] > > ------------------------------------------------------------------------ > > Subject: > request for review (M): 4965777 GC changes to support use of discovered > field for pending references > From: > Ramki Ramakrishna > Date: > Mon, 05 Sep 2011 02:16:18 -0700 > To: > "hotspot-gc-dev at openjdk.java.net" , > core-libs-dev at openjdk.java.net > > To: > "hotspot-gc-dev at openjdk.java.net" , > core-libs-dev at openjdk.java.net > > > > CR's 4243978 and 4268317 have proposed to use the discovered field of > a java.lang.ref.reference object to link the objects in the pending list. > This requires changes in both GC and in the reference handler code. > The JVM adaptsso as to allow it to run either inside a newer JDK which > uses the > discovered field to link the references or inside an older JDK which > uses the > next field for that purpose. Although the JDK part of the changes are > also being submitted for review here, that part will be integrated as a > separate > CR and changeset into the JDK repo following the integration of the JVM > changes > into an appropriate version of the HotSpot (express) repos. > > JVM webrev: http://cr.openjdk.java.net/~ysr/4965777/hotspot/webrev/ > JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ > > Many thanks to Mandy Chung and John Coomes for advice and for > earlier reviews; and to Mandy for additional testing help. > > Thanks for any other reviews or comments. > -- ramki From y.s.ramakrishna at oracle.com Tue Sep 6 19:52:10 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 06 Sep 2011 12:52:10 -0700 Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references In-Reply-To: <4E650B94.10707@oracle.com> References: <4E649362.1060607@oracle.com> <4E64BAF1.5060705@oracle.com> <4E650717.7020600@oracle.com> <4E650B94.10707@oracle.com> Message-ID: <4E6679EA.9080501@oracle.com> [i left the embedded inlines below for the cores-lib folk who may have missed part of the exchange because of non-membership of the posters.] Hi Stefan -- On 09/05/11 10:49, Stefan Karlsson wrote: > Hi Ramki, > > On 09/05/2011 07:29 PM, Ramki Ramakrishna wrote: >> >> Hi Stefan -- >> >> Thanks for your prompt review! >> >> On 9/5/2011 5:05 AM, Stefan Karlsson wrote: >>> Hi Ramki, >>> >>> Your changes seems to be based on my changes to remove the >>> sentinelRef and use a self-looping end in the discovered lists, so my >>> review is based on that. >> >> Yes, that's correct. I should have remembered to mention that in my email >> to these review aliases. >> >>> >>> referenceProcessor.cpp: >>> >>> Why do you want to change the variable name to next_d? >>> 325 oop next_d = refs_list.head(); >> >> To keep from confusing it with the next field's name. Just a naming >> convention. >> (next_d == next discovered object) to keep confusion wrt "next" to a >> minimum >> for the unwary reader. >> >>> >>> This seems to be incorrect. The discovered list should never end with >>> NULL, since its self-looping. >>> 348 java_lang_ref_Reference::set_discovered(obj, old); // >>> old may be NULL >> >> Yes, I considered that, which was one of the reasons I wanted to place >> my changes >> on top of yours. However, it turns out that that protocol's only needed >> for objects that will end up on the discovered lists maintained by GC. >> Once pended, an object is never eligible to be discovered again >> (recall the next!=NULL check during reference discovery by GC), so >> the discovered field need not conform to the "never NULL" protocol >> necessary for not-yet-pended objects (present on the discovered >> lists of GC). > > OK, I see your point. IMHO it would be prudent to use the same EOL > marker for the pending list as for the discovered lists and the queued > references (through the next field), just for consistency. But I'll not > stress this point. I understand your concern. I will keep this in mind, as we watch any bug tail, but at the moment I'm inclined not to change the treatment of the pending list terminator in the same way as was done for the discovered list terminator. thanks again for your review! -- ramki > >> >>> >>> >>> instanceRefKlass.cpp: >>> >>> Typo, discoveredd -> discovered >>> 95 // In the case of older JDKs which do not use the discoveredd >>> 175 // In the case of older JDKs which do not use the discoveredd >>> 399 // In the case of older JDKs which do not use the discoveredd >> >> Fixed. >> >>> >>> Why was the contains check moved? >>> 207 if (!oopDesc::is_null(heap_oop) && contains(referent_addr)) { >> >> This was because the scanning should be based on containment of the >> oop in the interval of interest, but discovery of the oop is not. >> This is >> really a somewhat pedantic change to clarify the intent of the >> contains check >> rather than anything substantive, because in all of our current >> reference processors, whenever contains is non-degenerate (i.e. where it >> does not return true), discovery will never actually happen, so the two >> forms are behaviourally equivalent relative to our current set of >> allowed executions. I prefer the new form though because it clarifies >> that the interval is only used for filtering the scan and not for >> other matters. > > OK. > > StefanK > >> >> Reading the code though (both old and new), it seems as though this >> could be >> further cleaned up, but a clean-up that I prefer deferred to >> a separate changeset. >> >>> >>> >>> Reference.java: >>> >>> The last element in the pending list should point back to itself. >>> 102 * pending: next element in the pending list (or null >>> if last) >> >> See my point above regarding why that is not necessary. >> >> Let me know. >> -- ramki >> >>> >>> >>> StefanK >>> >>> On 09/05/2011 11:16 AM, Ramki Ramakrishna wrote: >>>> >>>> CR's 4243978 and 4268317 have proposed to use the discovered field of >>>> a java.lang.ref.reference object to link the objects in the pending >>>> list. >>>> This requires changes in both GC and in the reference handler code. >>>> The JVM adaptsso as to allow it to run either inside a newer JDK >>>> which uses the >>>> discovered field to link the references or inside an older JDK which >>>> uses the >>>> next field for that purpose. Although the JDK part of the changes are >>>> also being submitted for review here, that part will be integrated >>>> as a separate >>>> CR and changeset into the JDK repo following the integration of the >>>> JVM changes >>>> into an appropriate version of the HotSpot (express) repos. >>>> >>>> JVM webrev: http://cr.openjdk.java.net/~ysr/4965777/hotspot/webrev/ >>>> JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ >>>> >>>> Many thanks to Mandy Chung and John Coomes for advice and for >>>> earlier reviews; and to Mandy for additional testing help. >>>> >>>> Thanks for any other reviews or comments. >>>> -- ramki >>> > From mandy.chung at oracle.com Wed Sep 7 00:49:38 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 06 Sep 2011 17:49:38 -0700 Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references In-Reply-To: <4E649362.1060607@oracle.com> References: <4E649362.1060607@oracle.com> Message-ID: <4E66BFA2.4080506@oracle.com> Hi Ramki, I reviewed the JDK webrev: > JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ The change looks good. I ran the JCK tests on solaris-i586 that I can reproduce the bug with JDK 7 and verify that they pass with your fix. It'd be good to write a regression test for this bug to be included in the jdk fix. I can help writing it if you want. I didn't review the hotspot change but had a quick scan on it. There is a typo "ir" in referenceProcessor.hpp L302 that I think you meant "or" 302 // and thus whether ir not it uses the discovered field to chain Thanks for fixing this long standing bug. Mandy On 9/5/11 2:16 AM, Ramki Ramakrishna wrote: > > CR's 4243978 and 4268317 have proposed to use the discovered field of > a java.lang.ref.reference object to link the objects in the pending list. > This requires changes in both GC and in the reference handler code. > The JVM adaptsso as to allow it to run either inside a newer JDK which > uses the > discovered field to link the references or inside an older JDK which > uses the > next field for that purpose. Although the JDK part of the changes are > also being submitted for review here, that part will be integrated as > a separate > CR and changeset into the JDK repo following the integration of the > JVM changes > into an appropriate version of the HotSpot (express) repos. > > JVM webrev: http://cr.openjdk.java.net/~ysr/4965777/hotspot/webrev/ > JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ > > Many thanks to Mandy Chung and John Coomes for advice and for > earlier reviews; and to Mandy for additional testing help. > > Thanks for any other reviews or comments. > -- ramki From y.s.ramakrishna at oracle.com Wed Sep 7 00:56:32 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Tue, 06 Sep 2011 17:56:32 -0700 Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references In-Reply-To: <4E66BFA2.4080506@oracle.com> References: <4E649362.1060607@oracle.com> <4E66BFA2.4080506@oracle.com> Message-ID: <4E66C140.1000302@oracle.com> Hi Mandy -- On 09/06/11 17:49, Mandy Chung wrote: > Hi Ramki, > > I reviewed the JDK webrev: >> JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ > > The change looks good. I ran the JCK tests on solaris-i586 > that I can reproduce the bug with JDK 7 and verify that they pass > with your fix. Thanks for the review, the testing and for your help with this CR. > > It'd be good to write a regression test for this bug to be included > in the jdk fix. I can help writing it if you want. Yes, that would be great if you could help write that, Mandy. I'll contact you off-line on that. > > I didn't review the hotspot change but had a quick scan on it. > There is a typo "ir" in referenceProcessor.hpp L302 that I think you > meant "or" > > 302 // and thus whether ir not it uses the discovered field to chain I'll fix that. -- ramki > > Thanks for fixing this long standing bug. > Mandy > > On 9/5/11 2:16 AM, Ramki Ramakrishna wrote: >> >> CR's 4243978 and 4268317 have proposed to use the discovered field of >> a java.lang.ref.reference object to link the objects in the pending list. >> This requires changes in both GC and in the reference handler code. >> The JVM adaptsso as to allow it to run either inside a newer JDK which >> uses the >> discovered field to link the references or inside an older JDK which >> uses the >> next field for that purpose. Although the JDK part of the changes are >> also being submitted for review here, that part will be integrated as >> a separate >> CR and changeset into the JDK repo following the integration of the >> JVM changes >> into an appropriate version of the HotSpot (express) repos. >> >> JVM webrev: http://cr.openjdk.java.net/~ysr/4965777/hotspot/webrev/ >> JDK webrev: http://cr.openjdk.java.net/~ysr/4965777/jdk/webrev/ >> >> Many thanks to Mandy Chung and John Coomes for advice and for >> earlier reviews; and to Mandy for additional testing help. >> >> Thanks for any other reviews or comments. >> -- ramki > From weijun.wang at oracle.com Wed Sep 7 00:57:18 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 07 Sep 2011 00:57:18 +0000 Subject: hg: jdk8/tl/jdk: 7067974: multiple ETYPE-INFO-ENTRY with same etype and different salt Message-ID: <20110907005728.86F3B4740B@hg.openjdk.java.net> Changeset: c62794c9caea Author: weijun Date: 2011-09-07 08:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c62794c9caea 7067974: multiple ETYPE-INFO-ENTRY with same etype and different salt Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/EncryptionKey.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/PAData.java + test/sun/security/krb5/auto/DupEtypes.java ! test/sun/security/krb5/auto/KDC.java From weijun.wang at oracle.com Wed Sep 7 02:27:18 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 07 Sep 2011 10:27:18 +0800 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: References: <4E663868.8040606@oracle.com> Message-ID: <4E66D686.2050008@oracle.com> Updated: root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ I also update Makefile to put jdk_sound to its correct alphabetical position. Thanks Max On 09/07/2011 02:30 AM, Kelly O'Hair wrote: > Looks fine. > > But the files make/jprt.properties in both the root repository and the jdk repository > will minor changes to add jdk_sound as a new test for JPRT. > You can place it in the jprt.make.rule.all.test.targets list. > > -kto > > On Sep 6, 2011, at 8:12 AM, Weijun Wang wrote: > >> Hi Kelly >> >> Webrev at http://cr.openjdk.java.net/~weijun/7087428/webrev.00/ >> >> Basically I'd like jdk_misc batch to contain only "headless" tests and move all the others into their own batch. >> >> Changes: >> >> 1. Move javax/imageio, javax/print, sun/pisces to jdk_awt >> 2. Move com/sun/java/swing to jdk_swing >> 3. Move com/sun/org/apache/xml/internal/security to jdk_security3 >> 4. Create a separate batch jdk_sound for javax/sound >> 5. Divide demo to different parts and move demo/jfc to jdk_swing. If the demo dir is moved to some other directory later, more updates will be needed. >> >> Please note that I change com/sun/java to com/sun/java/swing, and com/sun/org to com/sun/org/apache/xml/internal/security, since those are the only sub-dir there. There might be other sub-dirs later. >> >> Thanks >> Max >> >> -------- Original Message -------- >> 7087428: move client tests out of jdk_misc >> >> === *Description* ============================================================ >> The jdk_misc batch in test/Makefile contains tests for swing, sound etc, They should be moved to their own batches. >> > From joe.darcy at oracle.com Wed Sep 7 04:20:12 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 07 Sep 2011 04:20:12 +0000 Subject: hg: jdk8/tl/jdk: 7086192: (reflect) Have TypeVariable extend AnnotatedElement Message-ID: <20110907042022.1B78747413@hg.openjdk.java.net> Changeset: fa1e7738a136 Author: darcy Date: 2011-09-06 21:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fa1e7738a136 7086192: (reflect) Have TypeVariable extend AnnotatedElement Reviewed-by: mcimadamore ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/reflect/TypeVariable/TestAnnotatedElement.java From jeannette.hung at oracle.com Wed Sep 7 04:44:20 2011 From: jeannette.hung at oracle.com (Jeannette Hung) Date: Tue, 6 Sep 2011 21:44:20 -0700 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: <4E66D686.2050008@oracle.com> References: <4E663868.8040606@oracle.com> <4E66D686.2050008@oracle.com> Message-ID: Including 2d-dev, since javax/imageio, javax/print, sun/pisces, is 2d code. On Sep 6, 2011, at 7:27 PM, Weijun Wang wrote: > Updated: > > root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ > jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ > > I also update Makefile to put jdk_sound to its correct alphabetical position. > > Thanks > Max > > > On 09/07/2011 02:30 AM, Kelly O'Hair wrote: >> Looks fine. >> >> But the files make/jprt.properties in both the root repository and the jdk repository >> will minor changes to add jdk_sound as a new test for JPRT. >> You can place it in the jprt.make.rule.all.test.targets list. >> >> -kto >> >> On Sep 6, 2011, at 8:12 AM, Weijun Wang wrote: >> >>> Hi Kelly >>> >>> Webrev at http://cr.openjdk.java.net/~weijun/7087428/webrev.00/ >>> >>> Basically I'd like jdk_misc batch to contain only "headless" tests and move all the others into their own batch. >>> >>> Changes: >>> >>> 1. Move javax/imageio, javax/print, sun/pisces to jdk_awt >>> 2. Move com/sun/java/swing to jdk_swing >>> 3. Move com/sun/org/apache/xml/internal/security to jdk_security3 >>> 4. Create a separate batch jdk_sound for javax/sound >>> 5. Divide demo to different parts and move demo/jfc to jdk_swing. If the demo dir is moved to some other directory later, more updates will be needed. >>> >>> Please note that I change com/sun/java to com/sun/java/swing, and com/sun/org to com/sun/org/apache/xml/internal/security, since those are the only sub-dir there. There might be other sub-dirs later. >>> >>> Thanks >>> Max >>> >>> -------- Original Message -------- >>> 7087428: move client tests out of jdk_misc >>> >>> === *Description* ============================================================ >>> The jdk_misc batch in test/Makefile contains tests for swing, sound etc, They should be moved to their own batches. >>> >> From Alan.Bateman at oracle.com Wed Sep 7 11:07:18 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Sep 2011 12:07:18 +0100 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: <4E66D686.2050008@oracle.com> References: <4E663868.8040606@oracle.com> <4E66D686.2050008@oracle.com> Message-ID: <4E675066.5040005@oracle.com> Weijun Wang wrote: > Updated: > > root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ > jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ > > I also update Makefile to put jdk_sound to its correct alphabetical > position. The changes look okay to me. The jdk_misc batch is still an odd mix of tests but clearly fine grain splitting will lead to too many tiny batches. I don't know what to say about the jdk_swing and jdk_awt batches. It does seem a bit strange to have some 2d tests in the jdk_swing batch and others in the jdk_awt batch. I haven't seen any change-sets from folks in those areas adding or removing tests from the problem list so it's possible that they aren't using the make file to run the tests. -Alan. From kelly.ohair at oracle.com Wed Sep 7 15:39:02 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 7 Sep 2011 08:39:02 -0700 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: <4E66D686.2050008@oracle.com> References: <4E663868.8040606@oracle.com> <4E66D686.2050008@oracle.com> Message-ID: <3F6822F6-A433-4268-A3C8-6EFE2D1548D7@oracle.com> Looks great. Thanks for taking care of this. -kto On Sep 6, 2011, at 7:27 PM, Weijun Wang wrote: > Updated: > > root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ > jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ > > I also update Makefile to put jdk_sound to its correct alphabetical position. > > Thanks > Max > > > On 09/07/2011 02:30 AM, Kelly O'Hair wrote: >> Looks fine. >> >> But the files make/jprt.properties in both the root repository and the jdk repository >> will minor changes to add jdk_sound as a new test for JPRT. >> You can place it in the jprt.make.rule.all.test.targets list. >> >> -kto >> >> On Sep 6, 2011, at 8:12 AM, Weijun Wang wrote: >> >>> Hi Kelly >>> >>> Webrev at http://cr.openjdk.java.net/~weijun/7087428/webrev.00/ >>> >>> Basically I'd like jdk_misc batch to contain only "headless" tests and move all the others into their own batch. >>> >>> Changes: >>> >>> 1. Move javax/imageio, javax/print, sun/pisces to jdk_awt >>> 2. Move com/sun/java/swing to jdk_swing >>> 3. Move com/sun/org/apache/xml/internal/security to jdk_security3 >>> 4. Create a separate batch jdk_sound for javax/sound >>> 5. Divide demo to different parts and move demo/jfc to jdk_swing. If the demo dir is moved to some other directory later, more updates will be needed. >>> >>> Please note that I change com/sun/java to com/sun/java/swing, and com/sun/org to com/sun/org/apache/xml/internal/security, since those are the only sub-dir there. There might be other sub-dirs later. >>> >>> Thanks >>> Max >>> >>> -------- Original Message -------- >>> 7087428: move client tests out of jdk_misc >>> >>> === *Description* ============================================================ >>> The jdk_misc batch in test/Makefile contains tests for swing, sound etc, They should be moved to their own batches. >>> >> From kelly.ohair at oracle.com Wed Sep 7 15:43:44 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 7 Sep 2011 08:43:44 -0700 Subject: code review request: 7087428: move client tests out of jdk_misc In-Reply-To: <4E675066.5040005@oracle.com> References: <4E663868.8040606@oracle.com> <4E66D686.2050008@oracle.com> <4E675066.5040005@oracle.com> Message-ID: <4546D8D0-0135-476A-A340-878547762C3C@oracle.com> On Sep 7, 2011, at 4:07 AM, Alan Bateman wrote: > Weijun Wang wrote: >> Updated: >> >> root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/ >> jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/ >> >> I also update Makefile to put jdk_sound to its correct alphabetical position. > The changes look okay to me. The jdk_misc batch is still an odd mix of tests but clearly fine grain splitting will lead to too many tiny batches. > > I don't know what to say about the jdk_swing and jdk_awt batches. It does seem a bit strange to have some 2d tests in the jdk_swing batch and others in the jdk_awt batch. I haven't seen any change-sets from folks in those areas adding or removing tests from the problem list so it's possible that they aren't using the make file to run the tests. Not sure they run these tests much from the Makefile. Originally I had to corral them off because they belonged to a set of tests that only worked with a DISPLAY setup on Solaris/Linux, and they seemed to poison the DISPLAY with strange settings. That's when I created a unique VNC display on the JPRT driver machine for each user job in JPRT, starting the DISPLAY fresh each time and killing it off when the job was done, so the poisoning was contained and didn't impact other user jobs. Last time I ran them, they seemed to run ok. (and jdk_misc has some tests that need a DISPLAY too I think). We should probably warn Amy (QE) about these tests. :^( -kto From Alan.Bateman at oracle.com Wed Sep 7 16:32:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Sep 2011 17:32:48 +0100 Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references In-Reply-To: <4E66BFA2.4080506@oracle.com> References: <4E649362.1060607@oracle.com> <4E66BFA2.4080506@oracle.com> Message-ID: <4E679CB0.1010800@oracle.com> Mandy Chung wrote: > : > > It'd be good to write a regression test for this bug to be included > in the jdk fix. I can help writing it if you want. I looked at the changes in the jdk repository and they look good to me too. Adding the bit to the jdk_version_info structure is a neat way to deal with the mis-match until hotspot and the JDK meet up in a promoted build. Do you think this bit will be temporary or do you plan to remove it once the changes have got into all releases? On the test, I agree with Mandy that it would be good to have a test in the jdk repository. I assume this will need to wait until HotSpot is in a promoted build so it would need to be a follow-on changeset anyway. -Alan From y.s.ramakrishna at oracle.com Wed Sep 7 16:53:18 2011 From: y.s.ramakrishna at oracle.com (Ramki Ramakrishna) Date: Wed, 07 Sep 2011 09:53:18 -0700 Subject: request for review (M): 4965777 GC changes to support use of discovered field for pending references In-Reply-To: <4E679CB0.1010800@oracle.com> References: <4E649362.1060607@oracle.com> <4E66BFA2.4080506@oracle.com> <4E679CB0.1010800@oracle.com> Message-ID: <4E67A17E.9000303@oracle.com> On 9/7/2011 9:32 AM, Alan Bateman wrote: > Mandy Chung wrote: >> : >> >> It'd be good to write a regression test for this bug to be included >> in the jdk fix. I can help writing it if you want. > I looked at the changes in the jdk repository and they look good to me > too. Thanks for the review, Alan. > > Adding the bit to the jdk_version_info structure is a neat way to deal > with the mis-match until hotspot and the JDK meet up in a promoted > build. Do you think this bit will be temporary or do you plan to > remove it once the changes have got into all releases? Yes, it was Mandy's idea (thanks!) to use that structure. It's temporary only in a long-term sense. It'll be there for at least the next couple of HSX releases, and possibly beyond. There was no immediate plan for removing it, although as you say once all the JDK's have the changes, the JVM need not test for it and the bit can perhaps be reclaime, and the adaptivity of the JVM along that dimension dropped entirely. The idea, though, is also to allow the newer JVM's to be able to interoperate for a while yet (may be a year or more) with older JDK's, which assists with traiging and debugging of issues that involve both JDK and JVM (sometimes performance issues) -- a capability that some folks felt was definitely worthwhile. > > On the test, I agree with Mandy that it would be good to have a test > in the jdk repository. I assume this will need to wait until HotSpot > is in a promoted build so it would need to be a follow-on changeset > anyway. I'll work with Mandy on the test, and on the integration into the JDK repos. Yes, the JDK changes will need to wait until the HotSpot changes have been promoted and are used by JPRT. thanks. -- ramki > > -Alan From mandy.chung at oracle.com Wed Sep 7 20:43:01 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 07 Sep 2011 20:43:01 +0000 Subject: hg: jdk8/tl/jdk: 7078024: Update JDK service tag for JDK 8 Message-ID: <20110907204311.8AB2347446@hg.openjdk.java.net> Changeset: be949e12cab0 Author: mchung Date: 2011-09-07 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be949e12cab0 7078024: Update JDK service tag for JDK 8 Reviewed-by: paulk ! make/com/sun/servicetag/Makefile ! src/share/classes/com/sun/servicetag/Installer.java + src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java From weijun.wang at oracle.com Thu Sep 8 01:04:52 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 08 Sep 2011 01:04:52 +0000 Subject: hg: jdk8/tl/jdk: 7087428: move client tests out of jdk_misc Message-ID: <20110908010502.8232A4745B@hg.openjdk.java.net> Changeset: 6dab08f1cabb Author: weijun Date: 2011-09-08 09:04 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6dab08f1cabb 7087428: move client tests out of jdk_misc Reviewed-by: alanb, ohair ! make/jprt.properties ! test/Makefile From weijun.wang at oracle.com Thu Sep 8 01:06:20 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 08 Sep 2011 01:06:20 +0000 Subject: hg: jdk8/tl: 7087428: move client tests out of jdk_misc Message-ID: <20110908010620.E7A2E4745C@hg.openjdk.java.net> Changeset: b1d357ebf0cb Author: weijun Date: 2011-09-08 09:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b1d357ebf0cb 7087428: move client tests out of jdk_misc Reviewed-by: ohair, alanb ! make/jprt.properties From sean.coffey at oracle.com Thu Sep 8 17:11:26 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 08 Sep 2011 18:11:26 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Message-ID: <4E68F73E.9000800@oracle.com> http://bugs.sun.com/view_bug.do?bug_id=7082769 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ Bug fix where we ensure that the fd object is not disposed of until all streams are closed out. Testcase is a bulked up version of CR 6322678 (which wasn't committed at time of 6322678 fix). It includes create/close() calls for FileInputStream/FileOutputStream/RandomAccessFile which all reference the same file descriptor. Multi threaded access to the same file descriptor is also tested. Typo fix also as per http://bugs.sun.com/view_bug.do?bug_id=7087019 also included. regards, Sean. From weijun.wang at oracle.com Fri Sep 9 03:19:44 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 09 Sep 2011 03:19:44 +0000 Subject: hg: jdk8/tl/jdk: 7047200: keytool safe store Message-ID: <20110909032012.D2965474B7@hg.openjdk.java.net> Changeset: 0e6076fed003 Author: weijun Date: 2011-09-09 11:18 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e6076fed003 7047200: keytool safe store Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/trystore.sh From chris.hegarty at oracle.com Fri Sep 9 10:26:38 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Sep 2011 11:26:38 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use In-Reply-To: <4E68F73E.9000800@oracle.com> References: <4E68F73E.9000800@oracle.com> Message-ID: <4E69E9DE.50905@oracle.com> Sean, The changes look good, though I haven't gone through the test in much detail! One question that is not directly related to your changes, but may be applicable. Shouldn't the close on FileChannel also check the value of the use count before closing the native fd? For example: raf = new RandomAccessFile("test1", "rw"); fd = raf.getFD(); fos = new FileOutputStream(fd); fos.getChannel(); fis = new FileInputStream(fd); fos.close() fis.read() <<<<<<< will this fail ???? Yes the channel should be closed, but shouldn't the FileChannelImpl.close itself decrement the use count and not close the fd if it is still in use? -Chris On 08/09/2011 18:11, Se?n Coffey wrote: > http://bugs.sun.com/view_bug.do?bug_id=7082769 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ > > Bug fix where we ensure that the fd object is not disposed of until all > streams are closed out. > > Testcase is a bulked up version of CR 6322678 (which wasn't committed at > time of 6322678 fix). It includes create/close() calls for > FileInputStream/FileOutputStream/RandomAccessFile which all reference > the same file descriptor. Multi threaded access to the same file > descriptor is also tested. > > Typo fix also as per http://bugs.sun.com/view_bug.do?bug_id=7087019 also > included. > > regards, > Sean. > From Alan.Bateman at oracle.com Fri Sep 9 11:25:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Sep 2011 12:25:06 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use In-Reply-To: <4E68F73E.9000800@oracle.com> References: <4E68F73E.9000800@oracle.com> Message-ID: <4E69F792.8010907@oracle.com> Se?n Coffey wrote: > http://bugs.sun.com/view_bug.do?bug_id=7082769 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ > > Bug fix where we ensure that the fd object is not disposed of until > all streams are closed out. > > Testcase is a bulked up version of CR 6322678 (which wasn't committed > at time of 6322678 fix). It includes create/close() calls for > FileInputStream/FileOutputStream/RandomAccessFile which all reference > the same file descriptor. Multi threaded access to the same file > descriptor is also tested. > > Typo fix also as per http://bugs.sun.com/view_bug.do?bug_id=7087019 > also included. > I think the change are okay. There are other issues with sharing file descriptors between streams but your changes are a good improvement and eliminate the messy runningFinalizer code (which I think someone added to address a regression from a previous fix to an address another issue with sharing file descriptors). The coverage in the new test looks good but I think the code could be a bit cleaner. For example in TestFinalizer then it uses try-with-resources at L64 but not at L55. It uses /**/ style comments at L63 but // style at L76. Temporary file usage is also inconsistent, Test_ is created in the system temporary directory, Test6322678 in the working directory. Also the temporary file name is duplicated at L97. I think TestMultipleFD would be a lot cleaner with try-with-resources too. I also suspect the deletes at L138 and L156 may be failing on Windows. If you have time to do a bit of clean-up in the test then I think you are good to go. -Alan. From Alan.Bateman at oracle.com Fri Sep 9 12:09:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Sep 2011 13:09:10 +0100 Subject: test/java/lang/invoke/InvokeGenericTest.java Message-ID: <4E6A01E6.3030808@oracle.com> John, This test fails in the jdk8/tl because javac now defaults to source/target 8 and the test specifies -target 7 without specifying the source. This means we can run the java/lang/** tests without getting at least one failure. Any objection if I add -source 7 to the compile tag? I assume at some point these tests will move to source/target 8. -Alan diff --git a/test/java/lang/invoke/InvokeGenericTest.java b/test/java/lang/invoke/InvokeGenericTest.java --- a/test/java/lang/invoke/InvokeGenericTest.java +++ b/test/java/lang/invoke/InvokeGenericTest.java @@ -25,7 +25,7 @@ /* @test * @summary unit tests for java.lang.invoke.MethodHandle.invoke - * @compile -target 7 InvokeGenericTest.java + * @compile -source 7 -target 7 InvokeGenericTest.java * @run junit/othervm test.java.lang.invoke.InvokeGenericTest */ From sean.coffey at oracle.com Fri Sep 9 13:08:04 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 09 Sep 2011 14:08:04 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use In-Reply-To: <4E69F792.8010907@oracle.com> References: <4E68F73E.9000800@oracle.com> <4E69F792.8010907@oracle.com> Message-ID: <4E6A0FB4.4090508@oracle.com> Good points Alan. Coding styles probably differ from merging two testcases together. I'll clean up on the issues mentioned and send out the new webrev shortly. I thought about try with resources in a few places but it didn't always suit. Take for example the TestMultipleFD() method. The ordering of close call is important. I can get around that knowing that the close calls are made in opposite order to the streams/file's creation. However, the creation of the streams is also important since I take the file descriptor from the random access file (normally) - I might have to intermix try with resources and some try/finally blocks. regards, Sean. On 09/09/11 12:25, Alan Bateman wrote: > Se?n Coffey wrote: >> http://bugs.sun.com/view_bug.do?bug_id=7082769 >> >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ >> >> Bug fix where we ensure that the fd object is not disposed of until >> all streams are closed out. >> >> Testcase is a bulked up version of CR 6322678 (which wasn't >> committed at time of 6322678 fix). It includes create/close() calls >> for FileInputStream/FileOutputStream/RandomAccessFile which all >> reference the same file descriptor. Multi threaded access to the same >> file descriptor is also tested. >> >> Typo fix also as per http://bugs.sun.com/view_bug.do?bug_id=7087019 >> also included. >> > I think the change are okay. There are other issues with sharing file > descriptors between streams but your changes are a good improvement > and eliminate the messy runningFinalizer code (which I think someone > added to address a regression from a previous fix to an address > another issue with sharing file descriptors). > > The coverage in the new test looks good but I think the code could be > a bit cleaner. For example in TestFinalizer then it uses > try-with-resources at L64 but not at L55. It uses /**/ style comments > at L63 but // style at L76. Temporary file usage is also inconsistent, > Test_ is created in the system temporary directory, Test6322678 in the > working directory. Also the temporary file name is duplicated at L97. > I think TestMultipleFD would be a lot cleaner with try-with-resources > too. I also suspect the deletes at L138 and L156 may be failing on > Windows. If you have time to do a bit of clean-up in the test then I > think you are good to go. > > -Alan. > > From joe.darcy at oracle.com Fri Sep 9 13:24:36 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 Sep 2011 06:24:36 -0700 Subject: test/java/lang/invoke/InvokeGenericTest.java In-Reply-To: <4E6A01E6.3030808@oracle.com> References: <4E6A01E6.3030808@oracle.com> Message-ID: <4E6A1394.3030504@oracle.com> Hello. In langtools, our policy is *not* to have explicit -source or -target flags in the regression tests unless a non-default older source/target is needed. Unnecessary options have been removed from both langtools and jdk. [1] [2] So, I recommend the compile line for this test just be @compile InvokeGenericTest.java -Joe [1] 6843761: Update langtools tests to remove unncessary -source and -target options http://hg.openjdk.java.net/jdk7/tl/langtools/rev/84061bd68019 [2] 6907177: Update jdk tests to remove unncessary -source and -target options http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1755493c5774 Alan Bateman wrote: > John, > > This test fails in the jdk8/tl because javac now defaults to > source/target 8 and the test specifies -target 7 without specifying > the source. This means we can run the java/lang/** tests without > getting at least one failure. Any objection if I add -source 7 to the > compile tag? I assume at some point these tests will move to > source/target 8. > > -Alan > > > diff --git a/test/java/lang/invoke/InvokeGenericTest.java > b/test/java/lang/invoke/InvokeGenericTest.java > --- a/test/java/lang/invoke/InvokeGenericTest.java > +++ b/test/java/lang/invoke/InvokeGenericTest.java > @@ -25,7 +25,7 @@ > > /* @test > * @summary unit tests for java.lang.invoke.MethodHandle.invoke > - * @compile -target 7 InvokeGenericTest.java > + * @compile -source 7 -target 7 InvokeGenericTest.java > * @run junit/othervm test.java.lang.invoke.InvokeGenericTest > */ > From michael.x.mcmahon at oracle.com Fri Sep 9 13:37:55 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Fri, 09 Sep 2011 13:37:55 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110909133824.D9943474DE@hg.openjdk.java.net> Changeset: e8eee45e1ca5 Author: michaelm Date: 2011-09-09 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8eee45e1ca5 7085981: XXSocket types depend on impl finalizer to close if constructor throws exception Reviewed-by: alanb, chegar ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Socket.java Changeset: 0ba4b29c7d9a Author: michaelm Date: 2011-09-09 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ba4b29c7d9a Merge From michael.x.mcmahon at oracle.com Fri Sep 9 14:39:03 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Fri, 09 Sep 2011 14:39:03 +0000 Subject: hg: jdk8/tl/jdk: 7088747: Use multicatch in Socket constructor Message-ID: <20110909143914.896E1474E3@hg.openjdk.java.net> Changeset: e995c36bb1eb Author: michaelm Date: 2011-09-09 15:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e995c36bb1eb 7088747: Use multicatch in Socket constructor Reviewed-by: alanb ! src/share/classes/java/net/Socket.java From john.r.rose at oracle.com Fri Sep 9 19:15:55 2011 From: john.r.rose at oracle.com (John Rose) Date: Fri, 9 Sep 2011 12:15:55 -0700 Subject: test/java/lang/invoke/InvokeGenericTest.java In-Reply-To: <4E6A1394.3030504@oracle.com> References: <4E6A01E6.3030808@oracle.com> <4E6A1394.3030504@oracle.com> Message-ID: On Sep 9, 2011, at 6:24 AM, Joe Darcy wrote: > So, I recommend the compile line for this test just be > > @compile InvokeGenericTest.java I agree. Thanks, Joe. -- John From Alan.Bateman at oracle.com Fri Sep 9 19:23:18 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Sep 2011 20:23:18 +0100 Subject: test/java/lang/invoke/InvokeGenericTest.java In-Reply-To: References: <4E6A01E6.3030808@oracle.com> <4E6A1394.3030504@oracle.com> Message-ID: <4E6A67A6.5050204@oracle.com> John Rose wrote: > On Sep 9, 2011, at 6:24 AM, Joe Darcy wrote: > >> So, I recommend the compile line for this test just be >> >> @compile InvokeGenericTest.java > > I agree. Thanks, Joe. > > -- John Thanks Joe, thanks John. I'll get this done as this test failure has been annoying me. -Alan From jonathan.gibbons at oracle.com Sat Sep 10 00:19:08 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 10 Sep 2011 00:19:08 +0000 Subject: hg: jdk8/tl/langtools: 7073508: Regression: NullPointerException at com.sun.tools.javac.code.Lint$AugmentVisitor.augment Message-ID: <20110910001910.BF42247507@hg.openjdk.java.net> Changeset: 1ee9f9a91e9c Author: jjg Date: 2011-09-09 17:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ee9f9a91e9c 7073508: Regression: NullPointerException at com.sun.tools.javac.code.Lint$AugmentVisitor.augment Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/annotations/T7043371.java + test/tools/javac/annotations/T7073477.java From alan.bateman at oracle.com Sat Sep 10 13:56:53 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 10 Sep 2011 13:56:53 +0000 Subject: hg: jdk8/tl/jdk: 7089131: test/java/lang/invoke/InvokeGenericTest.java does not compile Message-ID: <20110910135724.F3D7547529@hg.openjdk.java.net> Changeset: c91176b44c9b Author: alanb Date: 2011-09-10 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c91176b44c9b 7089131: test/java/lang/invoke/InvokeGenericTest.java does not compile Reviewed-by: darcy, jrose ! test/java/lang/invoke/InvokeGenericTest.java From lana.steuck at oracle.com Sun Sep 11 06:05:54 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:05:54 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20110911060601.9987F47559@hg.openjdk.java.net> Changeset: ed8d94519a87 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ed8d94519a87 Added tag jdk8-b01 for changeset 949fb60ca830 ! .hgtags Changeset: cd0da00694fb Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cd0da00694fb Added tag jdk8-b02 for changeset ed8d94519a87 ! .hgtags Changeset: 60a68d688e24 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/60a68d688e24 Added tag jdk8-b03 for changeset cd0da00694fb ! .hgtags Changeset: cc1b599b986a Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc1b599b986a Added tag jdk8-b04 for changeset 60a68d688e24 ! .hgtags From lana.steuck at oracle.com Sun Sep 11 06:06:04 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:06:04 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20110911060604.492224755A@hg.openjdk.java.net> Changeset: 1034127ed402 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1034127ed402 Added tag jdk8-b01 for changeset 64df57a1edec ! .hgtags Changeset: 7dcb0307508f Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7dcb0307508f Added tag jdk8-b02 for changeset 1034127ed402 ! .hgtags Changeset: 3f6f08163331 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3f6f08163331 Added tag jdk8-b03 for changeset 7dcb0307508f ! .hgtags Changeset: 7d5d91fddbce Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7d5d91fddbce Added tag jdk8-b04 for changeset 3f6f08163331 ! .hgtags From lana.steuck at oracle.com Sun Sep 11 06:06:09 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:06:09 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20110911060609.822594755B@hg.openjdk.java.net> Changeset: ca4d6ad55a66 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ca4d6ad55a66 Added tag jdk8-b01 for changeset 4f0fcb812767 ! .hgtags Changeset: 7a74371ce0c6 Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7a74371ce0c6 Added tag jdk8-b02 for changeset ca4d6ad55a66 ! .hgtags Changeset: acbcadef0b21 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/acbcadef0b21 Added tag jdk8-b03 for changeset 7a74371ce0c6 ! .hgtags Changeset: ff0a3d78e7a2 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ff0a3d78e7a2 Added tag jdk8-b04 for changeset acbcadef0b21 ! .hgtags From lana.steuck at oracle.com Sun Sep 11 06:06:15 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:06:15 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20110911060628.2862C4755C@hg.openjdk.java.net> Changeset: b3c059de2a61 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b3c059de2a61 Added tag jdk8-b01 for changeset e9f118c2bd3c ! .hgtags Changeset: f497fac86cf9 Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f497fac86cf9 Added tag jdk8-b02 for changeset b3c059de2a61 ! .hgtags Changeset: 5df63fd8fa64 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5df63fd8fa64 Added tag jdk8-b03 for changeset f497fac86cf9 ! .hgtags Changeset: 5304c2a17d4b Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5304c2a17d4b Added tag jdk8-b04 for changeset 5df63fd8fa64 ! .hgtags Changeset: 9aca3534ddf4 Author: lana Date: 2011-09-10 21:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9aca3534ddf4 Merge From lana.steuck at oracle.com Sun Sep 11 06:06:24 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:06:24 +0000 Subject: hg: jdk8/tl/hotspot: 68 new changesets Message-ID: <20110911060844.E3E674755D@hg.openjdk.java.net> Changeset: 31e253c1da42 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31e253c1da42 Added tag jdk8-b01 for changeset 0cc8a70952c3 ! .hgtags Changeset: a3592789b47c Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3592789b47c Added tag jdk8-b02 for changeset 31e253c1da42 ! .hgtags Changeset: 20cac004a4f9 Author: dsamersoff Date: 2011-06-09 01:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20cac004a4f9 Merge Changeset: 1744e37e032b Author: dsamersoff Date: 2011-06-18 13:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1744e37e032b Merge Changeset: d425748f2203 Author: dcubed Date: 2011-06-23 20:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d425748f2203 7043987: 3/3 JVMTI FollowReferences is slow Summary: VM_HeapWalkOperation::doit() should only reset mark bits when necessary. Reviewed-by: dsamersoff, ysr, dholmes, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 88dce6a60ac8 Author: dcubed Date: 2011-06-29 20:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/88dce6a60ac8 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Summary: Call collect_stack_roots() before collect_simple_roots() as an optimization. Reviewed-by: ysr, dsamersoff, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 109d1d265924 Author: dholmes Date: 2011-07-02 04:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/109d1d265924 7052988: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk Changeset: 5447b2c582ad Author: coleenp Date: 2011-07-07 22:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5447b2c582ad Merge Changeset: bcc6475bc68f Author: coleenp Date: 2011-07-16 22:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcc6475bc68f Merge Changeset: 0b80db433fcb Author: dholmes Date: 2011-07-22 00:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b80db433fcb 7046490: Preallocated OOME objects should obey Throwable stack trace protocol Summary: Update the OOME stacktrace to contain Throwable.UNASSIGNED_STACK when the backtrace is filled in Reviewed-by: mchung, phh ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp Changeset: 8107273fd204 Author: coleenp Date: 2011-07-23 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8107273fd204 Merge Changeset: ca1f1753c866 Author: andrew Date: 2011-07-28 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca1f1753c866 7072341: enable hotspot builds on Linux 3.0 Summary: Add "3" to list of allowable versions Reviewed-by: kamg, chrisphi ! make/linux/Makefile Changeset: 14a2fd14c0db Author: johnc Date: 2011-08-01 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/14a2fd14c0db 7068240: G1: Long "parallel other time" and "ext root scanning" when running specific benchmark Summary: In root processing, move the scanning of the reference processor's discovered lists to before RSet updating and scanning. When scanning the reference processor's discovered lists, use a buffering closure so that the time spent copying any reference object is correctly attributed. Also removed a couple of unused and irrelevant timers. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 6aa4feb8a366 Author: johnc Date: 2011-08-02 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6aa4feb8a366 7069863: G1: SIGSEGV running SPECjbb2011 and -UseBiasedLocking Summary: Align the reserved size of the heap and perm to the heap region size to get a preferred heap base that is aligned to the region size, and call the correct heap reservation constructor. Also add a check in the heap reservation code that the reserved space starts at the requested address (if any). Reviewed-by: kvn, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: a20e6e447d3d Author: iveresov Date: 2011-08-05 16:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a20e6e447d3d 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008 Summary: Use mmap() instead of madvise(MADV_DONTNEED) to uncommit pages Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp Changeset: 7c2653aefc46 Author: iveresov Date: 2011-08-05 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c2653aefc46 7060836: RHEL 5.5 and 5.6 should support UseNUMA Summary: Add a wrapper for sched_getcpu() for systems where libc lacks it Reviewed-by: ysr Contributed-by: Andrew John Hughes ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: 41e6ee74f879 Author: kevinw Date: 2011-08-02 14:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41e6ee74f879 7072527: CMS: JMM GC counters overcount in some cases Summary: Avoid overcounting when CMS has concurrent mode failure. Reviewed-by: ysr Contributed-by: rednaxelafx at gmail.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp + test/gc/7072527/TestFullGCCount.java Changeset: e9db47a083cc Author: kevinw Date: 2011-08-11 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9db47a083cc Merge Changeset: 87e40b34bc2b Author: johnc Date: 2011-08-11 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/87e40b34bc2b 7074579: G1: JVM crash with JDK7 running ATG CRMDemo Fusion App Summary: Handlize MemoryUsage klass oop in createGCInfo routine Reviewed-by: tonyp, fparain, ysr, jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: f44782f04dd4 Author: tonyp Date: 2011-08-12 11:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f44782f04dd4 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally Summary: Refactor the allocation code during GC to use the G1AllocRegion abstraction. Use separate subclasses of G1AllocRegion for survivor and old regions. Avoid BOT updates and dirty survivor cards incrementally for the former. Reviewed-by: brutisso, johnc, ysr ! src/share/vm/gc_implementation/g1/g1AllocRegion.cpp ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp Changeset: 76b1a9420e3d Author: ysr Date: 2011-08-16 08:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/76b1a9420e3d Merge Changeset: 46cb9a7b8b01 Author: dsamersoff Date: 2011-08-10 15:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46cb9a7b8b01 7073913: The fix for 7017193 causes segfaults Summary: Buffer overflow in os::get_line_chars Reviewed-by: coleenp, dholmes, dcubed Contributed-by: aph at redhat.com ! src/share/vm/runtime/os.cpp Changeset: b1cbb0907b36 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1cbb0907b36 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 279ef1916773 Author: zgu Date: 2011-07-12 21:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/279ef1916773 7065535: Mistyped function name that disabled UseLargePages on Windows Summary: Missing suffix "A" of Windows API LookupPrivilegeValue failed finding function pointer, caused VM to disable UseLargePages option Reviewed-by: coleenp, phh ! src/os/windows/vm/os_windows.cpp Changeset: a68e11dceb83 Author: zgu Date: 2011-08-16 09:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a68e11dceb83 Merge Changeset: 00ed4ccfe642 Author: collins Date: 2011-08-17 07:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/00ed4ccfe642 Merge Changeset: 43f9d800f276 Author: iveresov Date: 2011-07-20 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43f9d800f276 7066339: Tiered: policy should make consistent decisions about osr levels Summary: Added feedback disabling flag to common(), fixed handling of TieredStopAtLevel. Reviewed-by: kvn, never ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp Changeset: 6a991dcb52bb Author: never Date: 2011-07-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a991dcb52bb 7012081: JSR 292: SA-JDI can't read MH/MT/Indy ConstantPool entries Reviewed-by: kvn, twisti, jrose ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecode.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeStream.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWideable.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/oops/generateOopMap.cpp Changeset: 3d42f82cd811 Author: kvn Date: 2011-07-21 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d42f82cd811 7063628: Use cbcond on T4 Summary: Add new short branch instruction to Hotspot sparc assembler. Reviewed-by: never, twisti, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e761e7e6e12 Author: kvn Date: 2011-07-26 19:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e761e7e6e12 7070134: Hotspot crashes with sigsegv from PorterStemmer Summary: Do not move data nodes which are attached to a predicate test to a dominating test. Reviewed-by: never ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp + test/compiler/7070134/Stemmer.java + test/compiler/7070134/Test7070134.sh + test/compiler/7070134/words Changeset: 0f34fdee809e Author: never Date: 2011-07-27 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f34fdee809e 7071427: AdapterFingerPrint can hold 8 entries per int Reviewed-by: kvn ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c7b60b601eb4 Author: kvn Date: 2011-07-27 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7b60b601eb4 7069452: Cleanup NodeFlags Summary: Remove flags which duplicate information in Node::NodeClasses. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp Changeset: d17bd0b18663 Author: twisti Date: 2011-07-28 02:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d17bd0b18663 7066143: JSR 292: Zero support after regressions from 7009923 and 7009309 Reviewed-by: jrose, twisti Contributed-by: Xerxes Ranby ! src/cpu/zero/vm/stack_zero.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce3e1d4dc416 Author: never Date: 2011-07-28 13:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce3e1d4dc416 7060619: C1 should respect inline and dontinline directives from CompilerOracle Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: c96c3eb1efae Author: kvn Date: 2011-07-29 09:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c96c3eb1efae 7068051: SIGSEGV in PhaseIdealLoop::build_loop_late_post Summary: Removed predicate cloning from loop peeling optimization and from split fall-in paths. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 4aa5974a06dd Author: kvn Date: 2011-08-06 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4aa5974a06dd 7075559: JPRT windows_x64 build failure Summary: use SA_CLASSDIR variable instead of dirsctory saclasses. Reviewed-by: kamg, dcubed ! make/linux/makefiles/defs.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/saproc.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: a3142bdb6707 Author: twisti Date: 2011-08-08 05:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3142bdb6707 7071823: Zero: zero/shark doesn't build after b147-fcs Reviewed-by: gbenson, twisti Contributed-by: Chris Phillips ! src/cpu/zero/vm/frame_zero.cpp + src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/shark/sharkContext.hpp Changeset: a19c671188cb Author: never Date: 2011-08-08 13:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a19c671188cb 7075623: 6990212 broke raiseException in 64 bit Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f1c12354c3f7 Author: roland Date: 2011-08-02 18:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1c12354c3f7 7074017: Introduce MemBarAcquireLock/MemBarReleaseLock nodes for monitor enter/exit code paths Summary: replace MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths with new MemBarAcquireLock/MemBarReleaseLock nodes Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 6987871cfb9b Author: kvn Date: 2011-08-10 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6987871cfb9b 7077439: Possible reference through NULL in loopPredicate.cpp:726 Summary: Use cl->is_valid_counted_loop() check. Reviewed-by: never ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp Changeset: 95134e034042 Author: kvn Date: 2011-08-11 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95134e034042 7063629: use cbcond in C2 generated code on T4 Summary: Use new short branch instruction in C2 generated code. Reviewed-by: never ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: fdb992d83a87 Author: twisti Date: 2011-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fdb992d83a87 7071653: JSR 292: call site change notification should be pushed not pulled Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp Changeset: 11211f7cb5a0 Author: kvn Date: 2011-08-16 11:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11211f7cb5a0 7079317: Incorrect branch's destination block in PrintoOptoAssembly output Summary: save/restore label and block in scratch_emit_size() Reviewed-by: never ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: 1af104d6cf99 Author: kvn Date: 2011-08-16 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1af104d6cf99 7079329: Adjust allocation prefetching for T4 Summary: on T4 2 BIS instructions should be issued to prefetch 64 bytes Reviewed-by: iveresov, phh, twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 381bf869f784 Author: twisti Date: 2011-08-17 05:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/381bf869f784 7079626: x64 emits unnecessary REX prefix Reviewed-by: kvn, iveresov, never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: bd87c0dcaba5 Author: twisti Date: 2011-08-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd87c0dcaba5 7079769: JSR 292: incorrect size() for CallStaticJavaHandle on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad Changeset: 739a9abbbd4b Author: kvn Date: 2011-08-18 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/739a9abbbd4b 7080431: VM asserts if specified size(x) in .ad is larger than emitted size Summary: Move code from finalize_offsets_and_shorten() to fill_buffer() to restore previous behavior. Reviewed-by: never ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp Changeset: de147f62e695 Author: kvn Date: 2011-08-19 08:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de147f62e695 Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 24cee90e9453 Author: jcoomes Date: 2011-08-17 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24cee90e9453 6791672: enable 1G and larger pages on solaris Reviewed-by: ysr, iveresov, johnc ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: 3be7439273c5 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3be7439273c5 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 8b135e6129d6 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b135e6129d6 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 52e4ba46751f Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52e4ba46751f 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh Changeset: bca686989d4b Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bca686989d4b 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 337ffef74c37 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/337ffef74c37 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 9f12ede5571a Author: jcoomes Date: 2011-08-19 14:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f12ede5571a Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/runtime/os.cpp Changeset: 7c29742c41b4 Author: jcoomes Date: 2011-08-19 14:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c29742c41b4 7081251: bump the hs22 build number to 02 Reviewed-by: johnc ! make/hotspot_version Changeset: ff53346271fe Author: brutisso Date: 2011-08-19 09:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff53346271fe 6814390: G1: remove the concept of non-generational G1 Summary: Removed the possibility to turn off generational mode for G1. Reviewed-by: johnc, ysr, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ae73da50be4b Author: tonyp Date: 2011-08-22 10:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae73da50be4b 7081064: G1: remove develop params G1FixedSurvivorSpaceSize, G1FixedTenuringThreshold, and G1FixedEdenSize Summary: Remove three develop parameters we don't use. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7f776886a215 Author: ysr Date: 2011-08-22 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f776886a215 6810861: G1: support -XX:+{PrintClassHistogram,HeapDump}{Before,After}FullGC Summary: Call {pre,post}_full_gc_dump() before and after a STW full gc of G1CollectedHeap. Also adjusted the prefix message, including the addition of missing whitespace. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: be05e987ba07 Author: ysr Date: 2011-08-22 23:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be05e987ba07 Merge Changeset: 2f27ed2a98fa Author: brutisso Date: 2011-08-23 11:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f27ed2a98fa 7082220: Visual Studio projects broken after change 7016797: Hotspot: securely/restrictive load dlls and new Summary: Add the psapi.lib library to Visual Studio projects Reviewed-by: jwilhelm, poonam, kamg ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: ff9ab6327924 Author: kvn Date: 2011-08-20 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff9ab6327924 7076831: TEST_BUG: compiler/5091921/Test7005594.java fails on LOW MEM SYSTEMS Summary: Run test only on systems with 2Gbyte or more memory. Don't zap heap to reduce execution time. Reviewed-by: iveresov ! test/compiler/5091921/Test7005594.sh Changeset: a594deb1d6dc Author: kvn Date: 2011-08-22 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a594deb1d6dc 7081926: assert(VM_Version::supports_sse2()) failed: must support Summary: fix assert, prefetchnta is supported since SSE not SSE2. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp Changeset: a70c2acb8f52 Author: kvn Date: 2011-08-25 18:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70c2acb8f52 Merge Changeset: 1520340a7f35 Author: kvn Date: 2011-08-26 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1520340a7f35 7083916: Bump the hs22 build number to 03 Reviewed-by: jcoomes Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 3a2fb61165df Author: jcoomes Date: 2011-08-31 13:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a2fb61165df Merge - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastAAccess0.java - agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeFastIAccess0.java Changeset: 0fa3ace511fe Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0fa3ace511fe Added tag jdk8-b03 for changeset 3a2fb61165df ! .hgtags Changeset: dce7d24674f4 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dce7d24674f4 Added tag jdk8-b04 for changeset 0fa3ace511fe ! .hgtags From lana.steuck at oracle.com Sun Sep 11 06:08:04 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 11 Sep 2011 06:08:04 +0000 Subject: hg: jdk8/tl/jdk: 22 new changesets Message-ID: <20110911061159.CB0194755E@hg.openjdk.java.net> Changeset: 13e70aa1398e Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13e70aa1398e Added tag jdk8-b01 for changeset 2cdbbc4a6359 ! .hgtags Changeset: dfa15ff0f99e Author: schien Date: 2011-08-25 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfa15ff0f99e Added tag jdk8-b02 for changeset 13e70aa1398e ! .hgtags Changeset: d8fccd6db59b Author: nloodin Date: 2011-08-31 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8fccd6db59b 7067811: Update demo/sample code to state it should not be used for production Summary: Added comment block after copyright block stating that code is unfit for production. Reviewed-by: ohair ! make/common/Defs.gmk ! make/mkdemo/Makefile ! make/mksample/Makefile ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java + src/share/demo/README ! src/share/demo/applets/ArcTest/ArcTest.java ! src/share/demo/applets/BarChart/BarChart.java ! src/share/demo/applets/Blink/Blink.java ! src/share/demo/applets/CardTest/CardTest.java ! src/share/demo/applets/Clock/Clock.java ! src/share/demo/applets/DitherTest/DitherTest.java ! src/share/demo/applets/DrawTest/DrawTest.java ! src/share/demo/applets/Fractal/CLSFractal.java ! src/share/demo/applets/GraphicsTest/AppletFrame.java ! src/share/demo/applets/GraphicsTest/GraphicsTest.java ! src/share/demo/applets/MoleculeViewer/Matrix3D.java ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/NervousText/NervousText.java ! src/share/demo/applets/SimpleGraph/GraphApplet.java ! src/share/demo/applets/SortDemo/BidirBubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/BubbleSortAlgorithm.java ! src/share/demo/applets/SortDemo/QSortAlgorithm.java ! src/share/demo/applets/SortDemo/SortAlgorithm.java ! src/share/demo/applets/SortDemo/SortItem.java ! src/share/demo/applets/SpreadSheet/SpreadSheet.java ! src/share/demo/applets/WireFrame/Matrix3D.java ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Destinations.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Group.java ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Modifier.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Node.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ResultSet.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Test.java ! src/share/demo/java2d/J2DBench/src/j2dbench/TestEnvironment.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/HTMLSeriesReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/IIOComparator.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/XMLHTMLReporter.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/MiscTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/RenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/InputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputStreamTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/iio/OutputTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextConstructionTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextMeasureTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextRenderTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/CompactLayout.java ! src/share/demo/java2d/J2DBench/src/j2dbench/ui/EnableButton.java ! src/share/demo/jfc/CodePointIM/CodePointIM.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethod.java ! src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java ! src/share/demo/jfc/FileChooserDemo/ExampleFileSystemView.java ! src/share/demo/jfc/FileChooserDemo/ExampleFileView.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Font2DTest/RangeMenu.java ! src/share/demo/jfc/Metalworks/AquaMetalTheme.java ! src/share/demo/jfc/Metalworks/BigContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/ContrastMetalTheme.java ! src/share/demo/jfc/Metalworks/DemoMetalTheme.java ! src/share/demo/jfc/Metalworks/GreenMetalTheme.java ! src/share/demo/jfc/Metalworks/KhakiMetalTheme.java ! src/share/demo/jfc/Metalworks/MetalThemeMenu.java ! src/share/demo/jfc/Metalworks/Metalworks.java ! src/share/demo/jfc/Metalworks/MetalworksDocumentFrame.java ! src/share/demo/jfc/Metalworks/MetalworksFrame.java ! src/share/demo/jfc/Metalworks/MetalworksHelp.java ! src/share/demo/jfc/Metalworks/MetalworksInBox.java ! src/share/demo/jfc/Metalworks/MetalworksPrefs.java ! src/share/demo/jfc/Metalworks/PropertiesMetalTheme.java ! src/share/demo/jfc/Metalworks/UISwitchListener.java ! src/share/demo/jfc/Notepad/ElementTreePanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jfc/SampleTree/DynamicTreeNode.java ! src/share/demo/jfc/SampleTree/SampleData.java ! src/share/demo/jfc/SampleTree/SampleTree.java ! src/share/demo/jfc/SampleTree/SampleTreeCellRenderer.java ! src/share/demo/jfc/SampleTree/SampleTreeModel.java ! src/share/demo/jfc/SwingApplet/SwingApplet.java ! src/share/demo/jfc/TableExample/JDBCAdapter.java ! src/share/demo/jfc/TableExample/OldJTable.java ! src/share/demo/jfc/TableExample/TableExample.java ! src/share/demo/jfc/TableExample/TableExample2.java ! src/share/demo/jfc/TableExample/TableExample3.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jfc/TableExample/TableMap.java ! src/share/demo/jfc/TableExample/TableSorter.java ! src/share/demo/jfc/TransparentRuler/transparentruler/Ruler.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipDirectoryStream.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js + src/share/sample/README ! src/share/sample/forkjoin/mergesort/MergeDemo.java ! src/share/sample/forkjoin/mergesort/MergeSort.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/chatserver/ChatServer.java ! src/share/sample/nio/chatserver/Client.java ! src/share/sample/nio/chatserver/ClientReader.java ! src/share/sample/nio/chatserver/DataReader.java ! src/share/sample/nio/chatserver/MessageReader.java ! src/share/sample/nio/chatserver/NameReader.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: c9956a6753fb Author: yhuang Date: 2011-08-14 23:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9956a6753fb 7066203: Update currency data to the latest ISO 4217 standard Reviewed-by: naoto ! make/java/util/FILES_properties.gmk ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! src/share/classes/sun/util/resources/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/CurrencyNames_es.properties + src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 954efddeee41 Author: mfang Date: 2011-08-17 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/954efddeee41 Merge ! make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java Changeset: f10654c857fd Author: mfang Date: 2011-08-29 17:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f10654c857fd Merge Changeset: 7989ee9fe673 Author: mfang Date: 2011-08-31 09:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7989ee9fe673 Merge Changeset: d977bcc79584 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d977bcc79584 Added tag jdk8-b03 for changeset 7989ee9fe673 ! .hgtags Changeset: 6664b47ddfd9 Author: prr Date: 2011-08-12 09:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6664b47ddfd9 7077423: Enable Xrender by default Reviewed-by: bae, jgodinez, ceisserer ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: f372807e122b Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f372807e122b Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 4a6dac089eac Author: lana Date: 2011-08-29 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a6dac089eac Merge Changeset: 4e0340c4f443 Author: rupashka Date: 2011-08-12 15:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e0340c4f443 7071609: javax/swing/JPopupMenu/6694823/bug6694823.java failed on solaris10 Reviewed-by: alexp ! test/javax/swing/JPopupMenu/6694823/bug6694823.java Changeset: 6ca2e7babaf0 Author: rupashka Date: 2011-08-17 19:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca2e7babaf0 7075563: Broken link in "javax.swing.SwingWorker" Reviewed-by: alexp ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/package.html ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/sun/swing/PrintingStatus.java Changeset: 0e03455d868c Author: rupashka Date: 2011-08-17 20:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e03455d868c 7032436: When running with the Nimbus look and feel, the JFileChooser does not display mnemonics Reviewed-by: alexp Contributed-by: Charles Lee ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties Changeset: 3bfa183cac32 Author: lana Date: 2011-08-17 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3bfa183cac32 Merge - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c Changeset: 7968d9677f9a Author: denis Date: 2011-08-23 17:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7968d9677f9a 7072645: Toolkit.addPropertyChangeListener(name, pcl) throws NPE for null name Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: e05ea8ab1807 Author: rupashka Date: 2011-08-29 16:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e05ea8ab1807 7030332: Default borders in tables looks incorrect JEditorPane Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/TableView.java + test/javax/swing/text/html/TableView/7030332/bug7030332.html + test/javax/swing/text/html/TableView/7030332/bug7030332.java + test/javax/swing/text/html/TableView/7030332/sample0.png + test/javax/swing/text/html/TableView/7030332/sample1.png + test/javax/swing/text/html/TableView/7030332/sample2.png + test/javax/swing/text/html/TableView/7030332/sample3.png + test/javax/swing/text/html/TableView/7030332/sample4.png Changeset: 1ffd61b6ab40 Author: lana Date: 2011-08-29 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ffd61b6ab40 Merge Changeset: 36f74da06285 Author: lana Date: 2011-08-29 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f74da06285 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: fc569517f3cf Author: lana Date: 2011-09-05 23:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc569517f3cf Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java - test/sun/nio/cs/TestISCII91.java Changeset: a6e1c192951a Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6e1c192951a Added tag jdk8-b04 for changeset fc569517f3cf ! .hgtags Changeset: 22c843299c5b Author: lana Date: 2011-09-10 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22c843299c5b Merge From jonathan.gibbons at oracle.com Mon Sep 12 18:39:46 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 12 Sep 2011 18:39:46 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20110912183950.64E52475B1@hg.openjdk.java.net> Changeset: edd7d9bd32dd Author: jjg Date: 2011-09-12 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/edd7d9bd32dd 7068451: Regression: javac compiles fixed sources against previous, not current, version of generated sources Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java + test/tools/javac/file/T7068451.java Changeset: f1431cace56e Author: jjg Date: 2011-09-12 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f1431cace56e Merge From sean.coffey at oracle.com Mon Sep 12 22:09:38 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 12 Sep 2011 23:09:38 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use In-Reply-To: <4E6A0FB4.4090508@oracle.com> References: <4E68F73E.9000800@oracle.com> <4E69F792.8010907@oracle.com> <4E6A0FB4.4090508@oracle.com> Message-ID: <4E6E8322.8090904@oracle.com> Cleaned up testcase (as per suggestions) is in latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8.2/ I've kept the try-with-resouces approach out of the TestMultipleFD method. It just complicates matters and with the closing order being important, it's easier to read with old style. Regards, Sean. On 09/09/2011 14:08, Se?n Coffey wrote: > Good points Alan. > > Coding styles probably differ from merging two testcases together. > I'll clean up on the issues mentioned and send out the new webrev > shortly. > > I thought about try with resources in a few places but it didn't > always suit. Take for example the TestMultipleFD() method. The > ordering of close call is important. I can get around that knowing > that the close calls are made in opposite order to the streams/file's > creation. However, the creation of the streams is also important since > I take the file descriptor from the random access file (normally) - I > might have to intermix try with resources and some try/finally blocks. > > regards, > Sean. > > On 09/09/11 12:25, Alan Bateman wrote: >> Se?n Coffey wrote: >>> http://bugs.sun.com/view_bug.do?bug_id=7082769 >>> >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8/ >>> >>> Bug fix where we ensure that the fd object is not disposed of until >>> all streams are closed out. >>> >>> Testcase is a bulked up version of CR 6322678 (which wasn't >>> committed at time of 6322678 fix). It includes create/close() calls >>> for FileInputStream/FileOutputStream/RandomAccessFile which all >>> reference the same file descriptor. Multi threaded access to the >>> same file descriptor is also tested. >>> >>> Typo fix also as per http://bugs.sun.com/view_bug.do?bug_id=7087019 >>> also included. >>> >> I think the change are okay. There are other issues with sharing file >> descriptors between streams but your changes are a good improvement >> and eliminate the messy runningFinalizer code (which I think someone >> added to address a regression from a previous fix to an address >> another issue with sharing file descriptors). >> >> The coverage in the new test looks good but I think the code could be >> a bit cleaner. For example in TestFinalizer then it uses >> try-with-resources at L64 but not at L55. It uses /**/ style comments >> at L63 but // style at L76. Temporary file usage is also >> inconsistent, Test_ is created in the system temporary directory, >> Test6322678 in the working directory. Also the temporary file name is >> duplicated at L97. I think TestMultipleFD would be a lot cleaner with >> try-with-resources too. I also suspect the deletes at L138 and L156 >> may be failing on Windows. If you have time to do a bit of clean-up >> in the test then I think you are good to go. >> >> -Alan. >> >> From lvjing at linux.vnet.ibm.com Tue Sep 13 07:51:29 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 13 Sep 2011 15:51:29 +0800 Subject: Timer thread termination may not be detected and cause non-clean VM shutdown Message-ID: <4E6F0B81.3040603@linux.vnet.ibm.com> Hello, I've meet a subtle issue with Timer. As we know, every Timer objects spawn a new thread (which is optionally a daemon thread). On VM shutdown, there is no way to ensure that the daemon thread terminates (cancel() and purge() only clear the queue). This can lead to non-clean VM shutdown (return non-zero exit code) and has caused problems in some applications especailly with attach API. Further, there is no way to determine when all tasks have completed after calling cancel(). This problem was encouraged to occur when the test machine was busy. The original failure occurs when created & destroyed 15 processes with 1 JVM's each (via JNI). It seems all versions of JDK has this issue. I was trying to make a simple testcase but no much progress - though logically I guess everyone can understand this easily. Current my workaround is to have some thread to join the Timer thread to wait its termination - but it seems have some side effect and cause problems. A quick idea to resolve the problem completely is to add a new API like "public void cancel(boolean wait)" to indicate if we will wait for the Timer threads to be terminated, or add some private methods to help the VM to do something to terminate the Timer. Any suggestions/comments? Thanks. -- Best Regards, Jimmy, Jing LV From Alan.Bateman at oracle.com Tue Sep 13 09:33:37 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Sep 2011 10:33:37 +0100 Subject: Timer thread termination may not be detected and cause non-clean VM shutdown In-Reply-To: <4E6F0B81.3040603@linux.vnet.ibm.com> References: <4E6F0B81.3040603@linux.vnet.ibm.com> Message-ID: <4E6F2371.2030900@oracle.com> Jing LV wrote: > Hello, > > I've meet a subtle issue with Timer. As we know, every Timer objects > spawn a new thread (which is optionally a daemon thread). On VM > shutdown, there is no way to ensure that the daemon thread terminates > (cancel() and purge() only clear the queue). This can lead to non-clean > VM shutdown (return non-zero exit code) and has caused problems in some > applications especailly with attach API. Further, there is no way to > determine when all tasks have completed after calling cancel(). > This problem was encouraged to occur when the test machine was busy. The > original failure occurs when created & destroyed 15 processes with 1 > JVM's each (via JNI). It seems all versions of JDK has this issue. > I was trying to make a simple testcase but no much progress - though > logically I guess everyone can understand this easily. Current my > workaround is to have some thread to join the Timer thread to wait its > termination - but it seems have some side effect and cause problems. > > A quick idea to resolve the problem completely is to add a new API like > "public void cancel(boolean wait)" to indicate if we will wait for the > Timer threads to be terminated, or add some private methods to help the > VM to do something to terminate the Timer. > > Any suggestions/comments? Thanks. > > I don't understand the comment about the problem when using the attach API. Are you see problems on the tool side or target VM side? Just curious as the attach API doesn't use Timer. When it does a thread dump then there will be timer threads but that's all. In any case I think we should encourage developers to move to ScheduledThreadPoolExecutor. -Alan. From Alan.Bateman at oracle.com Tue Sep 13 09:41:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Sep 2011 10:41:33 +0100 Subject: Code review request: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use In-Reply-To: <4E6E8322.8090904@oracle.com> References: <4E68F73E.9000800@oracle.com> <4E69F792.8010907@oracle.com> <4E6A0FB4.4090508@oracle.com> <4E6E8322.8090904@oracle.com> Message-ID: <4E6F254D.5060106@oracle.com> Se?n Coffey wrote: > Cleaned up testcase (as per suggestions) is in latest webrev : > http://cr.openjdk.java.net/~coffeys/webrev.7082769.7087019.jdk8.2/ > Updated test looks fine to me. Minor comment is that I assume the /timeout=100 in the @run tag isn't needed. -Alan. From David.Holmes at oracle.com Tue Sep 13 10:18:35 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 13 Sep 2011 20:18:35 +1000 Subject: Timer thread termination may not be detected and cause non-clean VM shutdown In-Reply-To: <4E6F0B81.3040603@linux.vnet.ibm.com> References: <4E6F0B81.3040603@linux.vnet.ibm.com> Message-ID: <4E6F2DFB.30301@oracle.com> On 13/09/2011 5:51 PM, Jing LV wrote: > I've meet a subtle issue with Timer. As we know, every Timer objects > spawn a new thread (which is optionally a daemon thread). On VM > shutdown, there is no way to ensure that the daemon thread terminates That's exactly the point of daemon threads - they get blown away when the VM terminates. If this is bad then don't use daemon threads. > (cancel() and purge() only clear the queue). This can lead to non-clean > VM shutdown (return non-zero exit code) and has caused problems in some > applications especailly with attach API. Further, there is no way to > determine when all tasks have completed after calling cancel(). Can you please give details of the problems that are encountered and under what circumstances. > This problem was encouraged to occur when the test machine was busy. The > original failure occurs when created& destroyed 15 processes with 1 > JVM's each (via JNI). It seems all versions of JDK has this issue. > I was trying to make a simple testcase but no much progress - though > logically I guess everyone can understand this easily. Current my > workaround is to have some thread to join the Timer thread to wait its > termination - but it seems have some side effect and cause problems. Again please provide details. I'm unclear how join()ing a thread would have problem causing side-effects. Though as a general rule you should never join() a Thread you didn't create/define (otherwise how can you know when it will terminate - the exception being when there is an API that causes the thread to terminate. > A quick idea to resolve the problem completely is to add a new API like > "public void cancel(boolean wait)" to indicate if we will wait for the > Timer threads to be terminated, or add some private methods to help the > VM to do something to terminate the Timer. Without knowing what problems are being encountered it is difficult to judge whether such an API would be of assistance. David Holmes > Any suggestions/comments? Thanks. > From sean.coffey at oracle.com Tue Sep 13 10:27:11 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 13 Sep 2011 10:27:11 +0000 Subject: hg: jdk8/tl/jdk: 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Message-ID: <20110913102739.9493E47630@hg.openjdk.java.net> Changeset: e0c1282a0ead Author: coffeys Date: 2011-09-13 11:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0c1282a0ead 7082769: FileInputStream/FileOutputStream/RandomAccessFile allow file descriptor be closed when still in use Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java + test/java/io/etc/FileDescriptorSharing.java From maurizio.cimadamore at oracle.com Tue Sep 13 13:16:34 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 13 Sep 2011 13:16:34 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20110913131642.8590147636@hg.openjdk.java.net> Changeset: ed338593b0b6 Author: mcimadamore Date: 2011-09-13 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ed338593b0b6 7086595: Error message bug: name of initializer is 'null' Summary: Implementation of MethodSymbol.location() should take into account static/instance initializers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/7086595/T7086595.java + test/tools/javac/7086595/T7086595.out ! test/tools/javac/Diagnostics/6860795/T6860795.out ! test/tools/javac/LocalClasses_2.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/TryWithResources/BadTwr.out ! test/tools/javac/TryWithResources/DuplicateResourceDecl.out + test/tools/javac/diags/examples/AlreadyDefinedClinit.java + test/tools/javac/diags/examples/KindnameInstanceInit.java + test/tools/javac/diags/examples/KindnameStaticInit.java ! test/tools/javac/generics/6910550/T6910550d.out Changeset: f595d8bc0599 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f595d8bc0599 7003595: IncompatibleClassChangeError with unreferenced local class with subclass Summary: Compiler omits unreferenced local inner classes from the InnerClasses attribute Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/7003595/T7003595.java + test/tools/javac/7003595/T7003595b.java Changeset: 3a2200681d69 Author: mcimadamore Date: 2011-09-13 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3a2200681d69 7086601: Error message bug: cause for method mismatch is 'null' Summary: Inference error during lub() does not set 'cause' for method resolution diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleUpperBounds.java + test/tools/javac/generics/inference/7086601/T7086601a.java + test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/generics/inference/7086601/T7086601b.java From lana.steuck at oracle.com Tue Sep 13 15:38:36 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 13 Sep 2011 15:38:36 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20110913153837.1B6294763C@hg.openjdk.java.net> Changeset: 3bec5415a227 Author: cl Date: 2011-08-18 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3bec5415a227 Added tag jdk8-b01 for changeset f42e3d9394b4 ! .hgtags Changeset: e01201e727da Author: neugens Date: 2011-07-26 21:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e01201e727da 7071275: Fix jdk7 references in README files, remove Forest Extension mentions Summary: Change documentation to remove reference to forest and reflect update to jdk8. Reviewed-by: ohair ! README ! README-builds.html Changeset: 69f592185747 Author: schien Date: 2011-08-24 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/69f592185747 Merge Changeset: 587bb549dff8 Author: schien Date: 2011-08-25 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/587bb549dff8 Added tag jdk8-b02 for changeset 69f592185747 ! .hgtags Changeset: 0b66a233bfb9 Author: schien Date: 2011-09-01 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0b66a233bfb9 Added tag jdk8-b03 for changeset 587bb549dff8 ! .hgtags Changeset: b910aac18c77 Author: schien Date: 2011-09-08 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b910aac18c77 Added tag jdk8-b04 for changeset 0b66a233bfb9 ! .hgtags Changeset: 123873564c23 Author: lana Date: 2011-09-13 08:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/123873564c23 Merge From michael.x.mcmahon at oracle.com Tue Sep 13 16:17:57 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 13 Sep 2011 17:17:57 +0100 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues Message-ID: <4E6F8235.3090801@oracle.com> Can I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/ The problem is when calling Runtime.exec(String) with a program name containing white space (on win32), it is difficult to distinguish between the program name and any parameters to it. Eg. "C:\A B\C D\E foo bar". Does this string represent the program name or are foo and bar arguments to a program called E? And there are many other possibilities. We just pass the whole string to windows and it does an ok job of disambiguating according to a defined algorithm. There are two problems however: 1) our security check doesn't do exactly the same thing as windows. So we may end up checking for a different file to what gets executed. 2) when the file doesn't exist, the error returned is truncated. In the example above, it would think C:\A is the non-existing program. The problem doesn't occur on Solaris/Linux because those OSes never try to disambiguate the way windows does. So, there is currently already consistency between the security check and the path to be run. Effectively, this way of calling Runtime.exec() never worked on those platforms and you always had to use one of the other multi-arg methods. So, the solution is first to refactor ProcessBuilder and ProcessImpl, by moving the generation of the exception down to ProcessImpl (when the file is not found) and also to move the security check down to ProcessImpl, where we can do the windows specific checking, and for Solaris and Windows there's no change in behavior beyond that. Thanks, Michael. From Alan.Bateman at oracle.com Tue Sep 13 17:26:24 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Sep 2011 18:26:24 +0100 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E6F8235.3090801@oracle.com> References: <4E6F8235.3090801@oracle.com> Message-ID: <4E6F9240.8040801@oracle.com> Michael McMahon wrote: > Can I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/ I scanned this briefly (I haven't done a detailed code review) but one initial comment is that Runtime.exec will now throw IllegalArgumenetException for that a case that isn't specified. The current javadoc says it is only thrown "If command is empty" and maybe this needs to be re-examined. I assume such cases would cause IOException to be thrown today. -Alan. From sebastian.sickelmann at gmx.de Tue Sep 13 19:57:41 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 13 Sep 2011 21:57:41 +0200 Subject: Remove public fields without breaking binary compatibility Message-ID: <4E6FB5B5.1040006@gmx.de> Hi i created a small concept-demo how i think we can manage to remove some flaws(public accessible fields) out of the jdk without breaking binary-compatibility. I uploaded the "code of cencept" to my github-incubator[0] and posted some description on my weblog[1]. It would be nice to get some discussion/comments on this, even if it destroys my dream that this can solve the above noted problem. I think discussion on the mailing list should be fine. Comments on my weblog are also welcome but i think discussion should went into the mailing-list. I copy the weblog-text here in a mailing-list compatible format. Sorry for the cross-post, i think core-libs-dev can be interessted in general in removing such fields. And I hope some of the mlvm people can say something about if this can be solved better on vm level. [0] https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess [1] http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/ ... more links at the bottom of the mail ---WEBLOG--COPY I think i made a small step in a concept how solutions that removes design flaws (such as public fields) can be solved in an binary compatible way. Public fields in public API are really nasty, and there isn't a solution how this can be resolved without completely removing this class (with a long deprecation phase in the meantime). It is because the missing encapsulation for accessing this field gives you no change to change behavoir (such as checking/permitting values and state). It is this nasty (for public instance fields) GET_FIELD bytecode instruction. It is like Dalibor Topic told it[2] : " Breaking binary compatibility is bad, bad, really, really bad" But than in saw a video[3] Virtual Extension Method with Brain Goetz which solves the compatibility problem introduced by extending the jdk for lambda expressions. After that i created a small concept-prototype which shows how it can work with simple bytecode transformations and invoke dynamic. I think there is much room for improvement and maybe it can be better implemented at the vm level, but actually i don't have the knowledge to do so. And in special : [4]"If you have a golden hammer,...." . I placed the implementation of the concept on my github incubator[5] What is this doing? 1. The build.xml looks complicated but this is not the point here. It compiles the needed things to show the concept here. There is much room optimizing this, but i don't do it because it is really unnecessary. 2. The Problem is the class OLD[6]. It has a public field cause which can be access be anyone. If you put this in an public API you can never change/remove this field without breaking binary compatibility. 2.1. There is a class NEW[7] which introduces the incompatibility in making the public field private. But is also introduces two methods that allows us to access the field in a controlled way. 2.2 There is a class NEW2[8] also which is nearer on my original problem (i tried to remove a public cause field in an exception-class in openjdk). It can throw an exception if changing the cause in the same manner java.lang.Throwable does it. 3. The Class GEN[9] generates three testclasses (TestOld,TestNew and TestNew2) with the same testsequence with is like this: OLD o = new OLD(); System.out.println(o.cause); o.cause = new RuntimeException("NEW"); System.out.println(o.cause); TestNew does it with NEW and TestNew2 does this with NEW2. I have done it with class generating techniques because it would not compile and it would need a really complicated build-file to show how it works, so it was easier to generate some bytecode. 4. The Class Main[10] does an overall test with the three testclasses TestOld, TestNew and TestNew2. [java] <> [java] java.lang.RuntimeException: INIT_OLD [java] java.lang.RuntimeException: NEW [java] <> [java] Exception in thread "main" java.lang.IllegalAccessError: tried to access field NEW.cause from class TestNew [java] at TestNew.testIt(TestNew.txt:3) [java] at Main.main(Main.java:7) The access of the cause field System.out.println(o.cause); crashes. The Test does not even reach the testcase TestNew2 But if you start the Main class with the jvmarg -javaagent:transformer.jar the output is [java] MOCKINJECT BCI [java] <> [java] java.lang.RuntimeException: INIT_OLD [java] java.lang.RuntimeException: NEW [java] <> [java] java.lang.RuntimeException: INIT_NEW [java] java.lang.RuntimeException: NEW [java] <> [java] java.lang.RuntimeException: INIT_NEW [java] ***java.lang.IllegalStateException: Not allowed to change I think this is realy cool. The methods getCause() and initCause are used instead of the field in the cases where the field is not accessable. 4. How does this work? The classes in the transformer.jar transforms the bytecode before loading into the vm. It replaces the GET_FIELD / PUT_FIELD instruction with something like: INVOKEDYNAMIC cause (LNEW;)Ljava/lang/Throwable; [Bootstrapper.getFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] INVOKEDYNAMIC cause (LNEW;Ljava/lang/Throwable;)V [Bootstrapper.setFunction(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; (6)] You can look the complete bytecode of the testclases if you search for the .txt files in the tmp dir after executing the build script. It invokes the bootstrap methods Bootstrapper.getFunction and Bootstrapper.setFunction in the Bootstrapper[11] class. 5. The Bootstapper class connects the invokedynamic call with the field if accessable or with the accordant annotated access method getCause or initCause. So what do you think? Please throw comments on me, also if you think binary compatible accessors for public fields is a really bad idea. I think there is much room for optimizations here, but first lets discuss about the idea and the concept. -- Sebastian [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-August/007539.html [3] http://medianetwork.oracle.com/media/show/16999 [4] http://en.wikipedia.org/wiki/Law_of_the_instrument [5] https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess [6] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/OLD.java#L1 [7] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/NEW.java#L1 [8] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/NEW2.java#L1 [9] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/generator/GEN.java#L1 [10] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/Main.java#L1 [11] https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/src/Bootstrapper.java#L1 From mandy.chung at oracle.com Tue Sep 13 20:54:39 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Sep 2011 13:54:39 -0700 Subject: Code review for 6915797 & 7090178 Message-ID: <4E6FC30F.2090505@oracle.com> 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Webrev at: http://cr.openjdk.java.net/~mchung/6915797/webrev.00/ The synopsis says it all. Thanks Mandy From olivier.lagneau at oracle.com Tue Sep 13 14:11:40 2011 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Tue, 13 Sep 2011 16:11:40 +0200 Subject: Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack Message-ID: <4E6F649C.8090005@oracle.com> Please review The implementation of a fast-path algorithm for optimizing the DecimalFormat(double, ...) call stack. The webrev is here : http://cr.openjdk.java.net/~alanb/7050528/webrev.01 As described in the CR evaluation and suggested fix, the speed-up on a micro-benchmark is ~x11 on Sparc-USIV arch and ~x10 on Sparc-T4. The footprint cost is ~6kbytes of static char array constant data to collect digits from integer values. New test dedicated at checking fast-path algorithm, as well as micro-benchmark, are coming soon in a subsequent webrev containing them. -- Olivier Lagneau, olivier.lagneau at oracle.com Oracle, 180 Av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE Phone : +33 4 76 18 80 09 Fax : +33 4 76 18 80 23 From mandy.chung at oracle.com Tue Sep 13 23:37:22 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 13 Sep 2011 23:37:22 +0000 Subject: hg: jdk8/tl/langtools: 7090297: Remove com.sun.tools.javac.Launcher from tools.jar Message-ID: <20110913233724.C1CA847657@hg.openjdk.java.net> Changeset: ca2e2b85f437 Author: mchung Date: 2011-09-13 16:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca2e2b85f437 7090297: Remove com.sun.tools.javac.Launcher from tools.jar Reviewed-by: jjg - src/share/classes/com/sun/tools/javac/Launcher.java From David.Holmes at oracle.com Wed Sep 14 02:14:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 14 Sep 2011 12:14:46 +1000 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E6F9240.8040801@oracle.com> References: <4E6F8235.3090801@oracle.com> <4E6F9240.8040801@oracle.com> Message-ID: <4E700E16.10205@oracle.com> On 14/09/2011 3:26 AM, Alan Bateman wrote: > Michael McMahon wrote: >> Can I get the following webrev reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/ > I scanned this briefly (I haven't done a detailed code review) but one > initial comment is that Runtime.exec will now throw > IllegalArgumenetException for that a case that isn't specified. The current > javadoc says it is only thrown "If command is empty" and maybe this needs to > be re-examined. I assume such cases would cause IOException to be thrown today. Aside: ProcessBuilder.start seems to have a number of undocumented failure modes compared to Runtime.exec I can't comment on the details of the windows logic, but the basic code refactoring seems okay to me. David > -Alan. From xueming.shen at oracle.com Wed Sep 14 03:09:09 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 13 Sep 2011 20:09:09 -0700 Subject: Code review for 6915797 & 7090178 In-Reply-To: <4E6FC30F.2090505@oracle.com> References: <4E6FC30F.2090505@oracle.com> Message-ID: <4E701AD5.8040508@oracle.com> Looks fine. On 9/13/2011 1:54 PM, Mandy Chung wrote: > 6915797: Remove sun.tools.jar.JarImageSource that is not used > 7090178: Move java.util.XMLUtils to another package to avoid split > package > > Webrev at: > http://cr.openjdk.java.net/~mchung/6915797/webrev.00/ > > The synopsis says it all. > > Thanks > Mandy From joe.darcy at oracle.com Wed Sep 14 06:04:44 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 13 Sep 2011 23:04:44 -0700 Subject: Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack In-Reply-To: <4E6F649C.8090005@oracle.com> References: <4E6F649C.8090005@oracle.com> Message-ID: <4E7043FC.4080705@oracle.com> Hello Olivier. Olivier Lagneau wrote: > Please review The implementation of a fast-path algorithm for > optimizing the > DecimalFormat(double, ...) call stack. > > The webrev is here : > http://cr.openjdk.java.net/~alanb/7050528/webrev.01 > > As described in the CR evaluation and suggested fix, > the speed-up on a micro-benchmark is ~x11 on Sparc-USIV arch and ~x10 > on Sparc-T4. > The footprint cost is ~6kbytes of static char array constant data to > collect digits from integer values. > > New test dedicated at checking fast-path algorithm, as well as > micro-benchmark, > are coming soon in a subsequent webrev containing them. > I have some initial comments on your changes. First, since the DecimalFormat class is serializable all the new fields should be transient and the readObject method should be updated to initialize them accordingly. However, I suggest putting the fast-path specific data into a package private static nested class of DecimalFormat and having a single transient pointer in DecimalFormat to the helper object. Since the general contract of NumberFormat is for external synchronization, it it not incorrect that the various new mutable fields are not declared to be volatile (or final). Also in terms of organizing data, I suggest using the initialize on demand holder class idiom for 6k of "The Fast Path for double Constants" info. That is, create a static nested class to store the data. This pattern ensures that the data is not loaded unnecessary and avoids the need for synchronization when the data is accessed. I've attached a patch below which changes the code to more closely follow JDK whitespace conventions. It also changes a number of instances of if (condition) foo = true; else foo = false; to foo = condition; as well as making the new fields transient (no readObject update) and using a sun.mis.FpUtils.isFinite method. Diff below. Cheers, -Joe 523c523,524 < // If fieldPosition is a DontCareFieldPosition instance we can try to go to fast-path code. --- > // If fieldPosition is a DontCareFieldPosition instance we can > // try to go to fast-path code. 525c526,527 < if (fieldPosition == DontCareFieldPosition.INSTANCE) tryFastPath = true; --- > if (fieldPosition == DontCareFieldPosition.INSTANCE) > tryFastPath = true; 892c894,895 < else if (fractionalPartAsInt != 0) boundIndex = nbFractionalDigits; --- > else if (fractionalPartAsInt != 0) > boundIndex = nbFractionalDigits; 909c912 < // Applies healf-even rounding rule. --- > // Applies half-even rounding rule. 912c915,916 < else return (number > perfectHalf); --- > else > return (number > perfectHalf); 916,917c920,922 < // Returns the exact number of digits (radix 10) representing < // the passed paramater i. Sets utility formating fields used in the algorithm --- > // Returns the exact number of digits (radix 10) representing the > // passed paramater i. Sets utility formating fields used in the > // algorithm 927,930c932,933 < } < else { < if (i == 99) isAllNines = true; < else isAllNines = false; --- > } else { > isAllNines = (i == 99); 934,937c937,938 < } < else { < if (i == 999) isAllNines = true; < else isAllNines = false; --- > } else { > isAllNines = (i == 999); 943,944c944 < if (i == 9999) isAllNines = true; < else isAllNines = false; --- > isAllNines = (i == 9999); 947,950c947,948 < } < else { < if (i == 99999) isAllNines = true; < else isAllNines = false; --- > } else { > isAllNines = (i == 99999); 954,955c952 < } < else { --- > } else { 958,959c955 < if (i == 999999) isAllNines = true; < else isAllNines = false; --- > isAllNines = (i == 999999); 962,965c958,959 < } < else if (i <= 9999999) { < if (i == 9999999) isAllNines = true; < else isAllNines = false; --- > } else if (i <= 9999999) { > isAllNines = (i == 9999999); 968,971c962,963 < } < else { < if (i == 99999999) isAllNines = true; < else isAllNines = false; --- > } else { > isAllNines = (i == 99999999); 975,978c967,968 < } < else if (i <= 999999999) { < if (i == 999999999) isAllNines = true; < else isAllNines = false; --- > } else if (i <= 999999999) { > isAllNines = (i == 999999999); 981,982c971 < } < else { --- > } else { 994c983,984 < if (i == 999) isAllNines = true; --- > if (i == 999) > isAllNines = true; 996,998c986,988 < } < else if (i < 10) { < if (i == 9) isAllNines = true; --- > } else if (i < 10) { > if (i == 9) > isAllNines = true; 1000,1002c990,992 < } < else { < if (i == 99) isAllNines = true; --- > } else { > if (i == 99) > isAllNines = true; 1008,1009c998,1000 < // Extracts and returns the 2 (Currency pattern) or 3 (Decimal pattern) < // digits int representing the fractional part of passed double. --- > // Extracts and returns the 2 (Currency pattern) or 3 (Decimal > // pattern) digits int representing the fractional part of passed > // double. 1017,1018c1008 < } < else { --- > } else { 1030d1019 < 1058,1060c1047,1048 < if ((minimumIntegerDigits == 1) && < (maximumIntegerDigits >= 10)) isFastPath = true; < else isFastPath = false; --- > isFastPath = ((minimumIntegerDigits == 1) && > (maximumIntegerDigits >= 10)); 1067,1070c1055,1059 < (maximumFractionDigits != 2)) isFastPath = false; < } < else if ((minimumFractionDigits != 0) || < (maximumFractionDigits != 3)) isFastPath = false; --- > (maximumFractionDigits != 2)) > isFastPath = false; > } else if ((minimumFractionDigits != 0) || > (maximumFractionDigits != 3)) > isFastPath = false; 1072,1073c1061,1062 < } < else isFastPath = false; --- > } else > isFastPath = false; 1121,1122c1110 < } < else { --- > } else { 1126,1127c1114 < } < else if (fastPathWasOn) { --- > } else if (fastPathWasOn) { 1145c1132,1133 < if (len == 1) digitsBuffer[lowerIndex] = digit; --- > if (len == 1) > digitsBuffer[lowerIndex] = digit; 1154c1142,1143 < if (--upperIndex > lowerIndex) digitsBuffer[upperIndex] = digit; --- > if (--upperIndex > lowerIndex) > digitsBuffer[upperIndex] = digit; 1165c1154,1155 < else suffix = charsPositiveSuffix; --- > else > suffix = charsPositiveSuffix; 1169c1159,1160 < if (len == 0) return; --- > if (len == 0) > return; 1181,1184c1172,1177 < if (len > 2) internalChars[dstLower] = suffix[1]; < if (len == 4) internalChars[dstUpper] = suffix[2]; < } < else System.arraycopy(suffix, 0, internalChars, startIndex, len); --- > if (len > 2) > internalChars[dstLower] = suffix[1]; > if (len == 4) > internalChars[dstUpper] = suffix[2]; > } else > System.arraycopy(suffix, 0, internalChars, startIndex, len); 1192c1185,1186 < // We localize digits only, taking into account currency/decimal fractional case --- > // We localize digits only, taking into account > // currency/decimal fractional case 1199,1201c1193,1195 < } < else { < // Cursor char is decimal separator or grouping char. Just reinit counter. --- > } else { > // Cursor char is decimal separator or grouping > // char. Just reinit counter. 1212c1206,1207 < if (!toBeRounded) fillDigit = '9'; --- > if (!toBeRounded) > fillDigit = '9'; 1234,1235c1229,1230 < } < else break; --- > } else > break; 1239,1240c1234,1237 < if (!toBeRounded || isCurrencyFormat) lastUsedIndex += fractionalLength; < else lastUsedIndex--; // fractional part absent --- > if (!toBeRounded || isCurrencyFormat) > lastUsedIndex += fractionalLength; > else > lastUsedIndex--; // fractional part absent 1269,1270c1266,1267 < } < else digitsBuffer[index] = DigitTens1000[number]; --- > } else > digitsBuffer[index] = DigitTens1000[number]; 1289,1290c1286 < } < else { --- > } else { 1292c1288,1289 < if (number == 0) index -= 4; --- > if (number == 0) > index -= 4; 1302,1303c1299 < } < else { --- > } else { 1352,1353c1348 < } < else { --- > } else { 1368,1369c1363 < } < else { --- > } else { 1373,1374c1367 < } < else { --- > } else { 1386c1379,1380 < else formatAllNinesCase(internalChars, startIndex, --- > else { > formatAllNinesCase(internalChars, startIndex, 1388a1383 > } 1391c1386,1387 < if (zeroDelta != 0) localizeDigits(internalChars, startIndex); --- > if (zeroDelta != 0) > localizeDigits(internalChars, startIndex); 1394c1390,1391 < if (isSuffixPresent) appendSuffix(negative, internalChars); --- > if (isSuffixPresent) > appendSuffix(negative, internalChars); 1411c1408,1409 < if (fastPathCheckNeeded) checkAndSetFastPathStatus(); --- > if (fastPathCheckNeeded) > checkAndSetFastPathStatus(); 1414,1416c1412,1413 < if (!Double.isNaN(number) && < !Double.isInfinite(number)) { < --- > // If finite > if (sun.misc.FpUtils.isFinite(number)) { 1427,1428c1424 < } < else if (number < 0.0) { // 2 tests for negative doubles --- > } else if (number < 0.0) { // 2 tests for negative doubles 1436,1437c1432 < } < else if ( 1/number > 0.0) { // 3 tests for positive zero. Not frequent. --- > } else if ( 1/number > 0.0) { // 3 tests for positive zero. Not frequent. 1442,1443c1437 < } < else { // 4 tests for negative zero (hopefully very rare) --- > } else { // 4 tests for negative zero (hopefully very rare) 3828c3822 < private boolean isAllNines = false; --- > private transient boolean isAllNines = false; 3831c3825 < private double remainingFractionalPart = 0.0d; --- > private transient double remainingFractionalPart = 0.0d; 3834c3828 < private int lastUsedIndex = 0; --- > private transient int lastUsedIndex = 0; 3837c3831 < private int nbGroupsNeeded = 0; --- > private transient int nbGroupsNeeded = 0; 3842c3836 < private boolean isFastPath = false; --- > private transient boolean isFastPath = false; 3845c3839 < private boolean fastPathCheckNeeded = true; --- > private transient boolean fastPathCheckNeeded = true; 3848,3849c3842,3843 < private char[] positiveFastPathContainer; < private char[] negativeFastPathContainer; --- > private transient char[] positiveFastPathContainer; > private transient char[] negativeFastPathContainer; 3852,3853c3846,3847 < private double[] safeMinusRoundingBounds = null; < private double[] safeMajorRoundingBounds = null; --- > private transient double[] safeMinusRoundingBounds = null; > private transient double[] safeMajorRoundingBounds = null; 3856,3858c3850,3852 < private boolean isSuffixPresent; < private char[] charsPositiveSuffix; < private char[] charsNegativeSuffix; --- > private transient boolean isSuffixPresent; > private transient char[] charsPositiveSuffix; > private transient char[] charsNegativeSuffix; 3861c3855 < private int zeroDelta; --- > private transient int zeroDelta; 3864c3858 < private char groupingChar; --- > private transient char groupingChar; 3867c3861 < private char decimalSeparatorChar; --- > private transient char decimalSeparatorChar; 3921,3922c3915,3918 < if (digitOne == '9') digitOne = '0'; < else digitOne++; --- > if (digitOne == '9') > digitOne = '0'; > else > digitOne++; 3927,3928c3923,3926 < if (digitTen == '9') digitTen = '0'; < else digitTen++; --- > if (digitTen == '9') > digitTen = '0'; > else > digitTen++; From michael.x.mcmahon at oracle.com Wed Sep 14 09:41:52 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 14 Sep 2011 10:41:52 +0100 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E6F9240.8040801@oracle.com> References: <4E6F8235.3090801@oracle.com> <4E6F9240.8040801@oracle.com> Message-ID: <4E7076E0.7070606@oracle.com> On 13/09/11 18:26, Alan Bateman wrote: > Michael McMahon wrote: >> Can I get the following webrev reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/ > I scanned this briefly (I haven't done a detailed code review) but one > initial comment is that Runtime.exec will now throw > IllegalArgumenetException for that a case that isn't specified. The > current javadoc says it is only thrown "If command is empty" and maybe > this needs to be re-examined. I assume such cases would cause > IOException to be thrown today. > > -Alan. We could add a sentence to the existing @throws clause for IAE. So it would say "If |command| is empty, or on some platforms, may be thrown if command contains illegal characters". I'm reluctant to be more precise than that, since as far as I know, there doesn't appear to be any illegal characters for filenames in Unix. - Michael. From Alan.Bateman at oracle.com Wed Sep 14 09:51:47 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Sep 2011 10:51:47 +0100 Subject: Code review for 6915797 & 7090178 In-Reply-To: <4E6FC30F.2090505@oracle.com> References: <4E6FC30F.2090505@oracle.com> Message-ID: <4E707933.9020807@oracle.com> Mandy Chung wrote: > 6915797: Remove sun.tools.jar.JarImageSource that is not used > 7090178: Move java.util.XMLUtils to another package to avoid split > package > > Webrev at: > http://cr.openjdk.java.net/~mchung/6915797/webrev.00/ > > The synopsis says it all. Mostly looks okay to me too. A few minor comments: - I assume Properties.XMLUtils can be private. - In the static initializer then CNFE is ignored but since XMLUtils doesn't have a fallback for when sun.util.xml.XMLUtils is not present then it might be better to have it fail earlier. -Alan. From Alan.Bateman at oracle.com Wed Sep 14 10:14:44 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Sep 2011 11:14:44 +0100 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E7076E0.7070606@oracle.com> References: <4E6F8235.3090801@oracle.com> <4E6F9240.8040801@oracle.com> <4E7076E0.7070606@oracle.com> Message-ID: <4E707E94.8020101@oracle.com> Michael McMahon wrote: > We could add a sentence to the existing @throws clause for IAE. > > So it would say "If |command| is empty, or on some platforms, may be > thrown if command contains illegal characters". > > I'm reluctant to be more precise than that, since as far as I know, > there doesn't appear to be > any illegal characters for filenames in Unix. I agree that you can't be too specific. I'm not sure if "illegal characters" should be in the wording as it begs the question as to which characters are legal. An alternative to trying to come up with some wording is to just specify the long standing behavior which seems to be that IOException is thrown if an I/O errors or the command line is malformed. I see David's reply pointing out that there are similar issues with ProcessBuilder. That is only specified to throw IndexOutOfBoundException if the command line is empty so it would be good to check those cases too. -Alan. From mandy.chung at oracle.com Wed Sep 14 15:34:37 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 14 Sep 2011 15:34:37 +0000 Subject: hg: jdk8/tl/jdk: 6915797: Remove sun.tools.jar.JarImageSource that is not used; ... Message-ID: <20110914153514.CB9074768E@hg.openjdk.java.net> Changeset: 04672e957da0 Author: mchung Date: 2011-09-14 08:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04672e957da0 6915797: Remove sun.tools.jar.JarImageSource that is not used 7090178: Move java.util.XMLUtils to another package to avoid split package Reviewed-by: alanb, sherman ! make/java/java/FILES_java.gmk ! make/sun/Makefile + make/sun/util/Makefile ! src/share/classes/java/util/Properties.java - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java + src/share/classes/sun/util/xml/XMLUtils.java From joe.darcy at oracle.com Wed Sep 14 18:32:27 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Sep 2011 18:32:27 +0000 Subject: hg: jdk8/tl/jdk: 6879143: java.math.BigInteger misses the xxxValueExact methods Message-ID: <20110914183251.BDFE947697@hg.openjdk.java.net> Changeset: 2a8072c7cf99 Author: darcy Date: 2011-09-14 11:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a8072c7cf99 6879143: java.math.BigInteger misses the xxxValueExact methods Reviewed-by: alanb ! src/share/classes/java/math/BigInteger.java + test/java/math/BigInteger/TestValueExact.java From jonathan.gibbons at oracle.com Wed Sep 14 19:08:30 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Sep 2011 19:08:30 +0000 Subject: hg: jdk8/tl/langtools: 7080267: Call to toString() from an ExpressionStatementTree doesn't take in consideration the "; " at the end Message-ID: <20110914190835.322694769A@hg.openjdk.java.net> Changeset: 0f3da6af9799 Author: jjg Date: 2011-09-14 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f3da6af9799 7080267: Call to toString() from an ExpressionStatementTree doesn't take in consideration the ";" at the end Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/TestToString.java From jonathan.gibbons at oracle.com Wed Sep 14 19:15:34 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Sep 2011 19:15:34 +0000 Subject: hg: jdk8/tl/langtools: 7090249: IllegalStateException from Trees.getScope when called from JSR 199 Message-ID: <20110914191536.C5AF44769B@hg.openjdk.java.net> Changeset: 1807fc3fd33c Author: jjg Date: 2011-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1807fc3fd33c 7090249: IllegalStateException from Trees.getScope when called from JSR 199 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java + test/tools/javac/api/TestGetScope.java From joe.darcy at oracle.com Wed Sep 14 19:38:05 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Sep 2011 12:38:05 -0700 Subject: JDK 8 code review request for 7088500 "there is no @since tag on SafeVarargs" Message-ID: <4E71029D.1070307@oracle.com> Hello. Please review the simple patch below to add an omitted @since tag to the SafeVargs annotation type, which was added to the platform as part of Project Coin in JDK 7. Thanks, -Joe --- a/src/share/classes/java/lang/SafeVarargs.java +++ b/src/share/classes/java/lang/SafeVarargs.java @@ -82,6 +82,7 @@ * * * + * @since 1.7 * @jls 4.7 Reifiable Types * @jls 8.4.1 Formal Parameters */ From mike.duigou at oracle.com Wed Sep 14 20:04:17 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Sep 2011 13:04:17 -0700 Subject: JDK 8 code review request for 7088500 "there is no @since tag on SafeVarargs" In-Reply-To: <4E71029D.1070307@oracle.com> References: <4E71029D.1070307@oracle.com> Message-ID: Looks good! On Sep 14 2011, at 12:38 , Joe Darcy wrote: > Hello. > > Please review the simple patch below to add an omitted @since tag to the SafeVargs annotation type, which was added to the platform as part of Project Coin in JDK 7. > > Thanks, > > -Joe > > --- a/src/share/classes/java/lang/SafeVarargs.java > +++ b/src/share/classes/java/lang/SafeVarargs.java > @@ -82,6 +82,7 @@ > * > * > * > + * @since 1.7 > * @jls 4.7 Reifiable Types > * @jls 8.4.1 Formal Parameters > */ > From joe.darcy at oracle.com Wed Sep 14 20:09:32 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Sep 2011 20:09:32 +0000 Subject: hg: jdk8/tl/jdk: 7088500: there is no @since tag on SafeVarargs Message-ID: <20110914200950.1E9784769E@hg.openjdk.java.net> Changeset: 84da01e00e6c Author: darcy Date: 2011-09-14 13:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84da01e00e6c 7088500: there is no @since tag on SafeVarargs Reviewed-by: mduigou ! src/share/classes/java/lang/SafeVarargs.java From jonathan.gibbons at oracle.com Wed Sep 14 22:50:36 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Sep 2011 22:50:36 +0000 Subject: hg: jdk8/tl/langtools: 7090700: fix for 7080267 breaks two tests Message-ID: <20110914225041.317D3476AB@hg.openjdk.java.net> Changeset: a6e2c1840ea1 Author: jjg Date: 2011-09-14 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6e2c1840ea1 7090700: fix for 7080267 breaks two tests Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/tree/JCTree.java From jonathan.gibbons at oracle.com Thu Sep 15 01:28:11 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 15 Sep 2011 01:28:11 +0000 Subject: hg: jdk8/tl/langtools: 7068437: Regression: Filer.getResource(SOURCE_OUTPUT, ...) no longer works in JDK 7 w/o -s Message-ID: <20110915012815.BE92D476BB@hg.openjdk.java.net> Changeset: 826ae6a2f27d Author: jjg Date: 2011-09-14 18:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/826ae6a2f27d 7068437: Regression: Filer.getResource(SOURCE_OUTPUT, ...) no longer works in JDK 7 w/o -s Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java + test/tools/javac/file/T7068437.java From yuka.kamiya at oracle.com Thu Sep 15 05:47:31 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 15 Sep 2011 05:47:31 +0000 Subject: hg: jdk8/tl/jdk: 7090844: Support a timezone whose offset is changed more than once in the future Message-ID: <20110915054803.75CD1476C7@hg.openjdk.java.net> Changeset: f114bddac6d6 Author: peytoia Date: 2011-09-15 14:45 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f114bddac6d6 7090844: Support a timezone whose offset is changed more than once in the future Reviewed-by: okutsu ! make/tools/src/build/tools/javazic/Mappings.java From yuka.kamiya at oracle.com Thu Sep 15 06:04:14 2011 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 15 Sep 2011 06:04:14 +0000 Subject: hg: jdk8/tl/jdk: 7090843: (tz) Support tzdata2011j Message-ID: <20110915060434.744A3476C9@hg.openjdk.java.net> Changeset: 5e403e9fa34a Author: peytoia Date: 2011-09-15 15:02 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e403e9fa34a 7090843: (tz) Support tzdata2011j Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From Alan.Bateman at oracle.com Thu Sep 15 10:00:43 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2011 11:00:43 +0100 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E707E94.8020101@oracle.com> References: <4E6F8235.3090801@oracle.com> <4E6F9240.8040801@oracle.com> <4E7076E0.7070606@oracle.com> <4E707E94.8020101@oracle.com> Message-ID: <4E71CCCB.4070705@oracle.com> Alan Bateman wrote: > Michael McMahon wrote: >> We could add a sentence to the existing @throws clause for IAE. >> >> So it would say "If |command| is empty, or on some platforms, may be >> thrown if command contains illegal characters". >> >> I'm reluctant to be more precise than that, since as far as I know, >> there doesn't appear to be >> any illegal characters for filenames in Unix. > I agree that you can't be too specific. I'm not sure if "illegal > characters" should be in the wording as it begs the question as to > which characters are legal. An alternative to trying to come up with > some wording is to just specify the long standing behavior which seems > to be that IOException is thrown if an I/O errors or the command line > is malformed. I see David's reply pointing out that there are similar > issues with ProcessBuilder. That is only specified to throw > IndexOutOfBoundException if the command line is empty so it would be > good to check those cases too. > > -Alan. I went through the rest of the changes. In src/solaris/classes/java/lang/ProcessImpl.java then the permission check needs to happen before the streams are redirected as otherwise it would allow an attacker to truncate arbitrary files. I think the alignment is a bit out at L132-142. In src/windows/classes/java/lang/ProcessImpl.java L211-216 is using toLowerCase (which is locale specific) and is assuming that prog and lprog will be the same length. The algorithm in getProgramPath seems okay although I think it can be cleaned up a bit (coding style is inconsistent with the rest of the file for example, is the StringBuilder actually needed). Minor comment is that "fileHasNoDot" is an odd method name, maybe hasDot would be nicer. There's space between File and "(" at line 323. A general comment is that what would it take to move this code away from using StringTokenizer? I realize Runtime.exec has javadoc to say that it uses StringTokenizer and I just wonder if that can be re-visited. -Alan. From jeroen at sumatra.nl Thu Sep 15 10:21:03 2011 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Thu, 15 Sep 2011 10:21:03 +0000 Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues In-Reply-To: <4E6F8235.3090801@oracle.com> References: <4E6F8235.3090801@oracle.com> Message-ID: Hi, I'm not a formal reviewer, but I've implemented this same thing for IKVM.NET which has to simulate the behavior of CreateProcess when running on Windows (because it uses the .NET API to start a process and that doesn't have this hack). Your algorithm doesn't match CreateProcess, because that also takes into account various directories to search (the application's directory, the current directory, the system directory, the windows directory and the PATH). Regards, Jeroen ________________________________________ From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Michael McMahon [michael.x.mcmahon at oracle.com] Sent: Tuesday, September 13, 2011 6:17 PM To: core-libs-dev at openjdk.java.net Subject: code review request: 7051946: Runtime.exec(String command) / ProcessBuilder command parsing issues Can I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7051946/webrev.1/ The problem is when calling Runtime.exec(String) with a program name containing white space (on win32), it is difficult to distinguish between the program name and any parameters to it. Eg. "C:\A B\C D\E foo bar". Does this string represent the program name or are foo and bar arguments to a program called E? And there are many other possibilities. We just pass the whole string to windows and it does an ok job of disambiguating according to a defined algorithm. There are two problems however: 1) our security check doesn't do exactly the same thing as windows. So we may end up checking for a different file to what gets executed. 2) when the file doesn't exist, the error returned is truncated. In the example above, it would think C:\A is the non-existing program. The problem doesn't occur on Solaris/Linux because those OSes never try to disambiguate the way windows does. So, there is currently already consistency between the security check and the path to be run. Effectively, this way of calling Runtime.exec() never worked on those platforms and you always had to use one of the other multi-arg methods. So, the solution is first to refactor ProcessBuilder and ProcessImpl, by moving the generation of the exception down to ProcessImpl (when the file is not found) and also to move the security check down to ProcessImpl, where we can do the windows specific checking, and for Solaris and Windows there's no change in behavior beyond that. Thanks, Michael. From chris.hegarty at oracle.com Thu Sep 15 11:46:08 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Sep 2011 12:46:08 +0100 Subject: [JDK] Code Review 7090499: missing rawtypes warnings in anonymous inner class Message-ID: <4E71E580.70203@oracle.com> This review is for the JDK part of CR 7090499: "missing rawtypes warnings in anonymous inner class". Recently, Sasha removed all warnings from some areas of the jdk and enabled -Werror. Once 7090499 is fixed in javac then the JDK build would fail if using raw types in any inner classes. SunPKCS11 is the only place in the jdk that uses a raw type and is built with -Xlint and -Werror. This is a trivial change to use the generified type. hg diff src/share/classes/sun/security/pkcs11/SunPKCS11.java diff -r 5e403e9fa34a src/share/classes/sun/security/pkcs11/SunPKCS11.java --- a/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu Sep 15 15:02:05 2011 +0900 +++ b/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu Sep 15 12:32:03 2011 +0100 @@ -1335,10 +1335,10 @@ public final class SunPKCS11 extends Aut return null; } - Class c = Class.forName - (defaultHandler, - true, - Thread.currentThread().getContextClassLoader()); + Class c = Class.forName + (defaultHandler, + true, + Thread.currentThread().getContextClassLoader()); return (CallbackHandler)c.newInstance(); } }); Thanks, -Chris. From maurizio.cimadamore at oracle.com Thu Sep 15 11:56:29 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 15 Sep 2011 12:56:29 +0100 Subject: [JDK] Code Review 7090499: missing rawtypes warnings in anonymous inner class In-Reply-To: <4E71E580.70203@oracle.com> References: <4E71E580.70203@oracle.com> Message-ID: <4E71E7ED.3000505@oracle.com> Looks good - thanks! Maurizio On 15/09/11 12:46, Chris Hegarty wrote: > This review is for the JDK part of CR 7090499: "missing rawtypes > warnings in anonymous inner class". > > Recently, Sasha removed all warnings from some areas of the jdk and > enabled -Werror. Once 7090499 is fixed in javac then the JDK build > would fail if using raw types in any inner classes. SunPKCS11 is the > only place in the jdk that uses a raw type and is built with -Xlint > and -Werror. > > This is a trivial change to use the generified type. > > hg diff src/share/classes/sun/security/pkcs11/SunPKCS11.java > diff -r 5e403e9fa34a src/share/classes/sun/security/pkcs11/SunPKCS11.java > --- a/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu > Sep 15 15:02:05 2011 +0900 > +++ b/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu > Sep 15 12:32:03 2011 +0100 > @@ -1335,10 +1335,10 @@ public final class SunPKCS11 extends Aut > return null; > } > > - Class c = Class.forName > - (defaultHandler, > - true, > - Thread.currentThread().getContextClassLoader()); > + Class c = Class.forName > + (defaultHandler, > + true, > + Thread.currentThread().getContextClassLoader()); > return (CallbackHandler)c.newInstance(); > } > }); > > Thanks, > -Chris. From Alan.Bateman at oracle.com Thu Sep 15 12:00:23 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Sep 2011 13:00:23 +0100 Subject: [JDK] Code Review 7090499: missing rawtypes warnings in anonymous inner class In-Reply-To: <4E71E580.70203@oracle.com> References: <4E71E580.70203@oracle.com> Message-ID: <4E71E8D7.9060209@oracle.com> Chris Hegarty wrote: > This review is for the JDK part of CR 7090499: "missing rawtypes > warnings in anonymous inner class". > > Recently, Sasha removed all warnings from some areas of the jdk and > enabled -Werror. Once 7090499 is fixed in javac then the JDK build > would fail if using raw types in any inner classes. SunPKCS11 is the > only place in the jdk that uses a raw type and is built with -Xlint > and -Werror. > > This is a trivial change to use the generified type. > > hg diff src/share/classes/sun/security/pkcs11/SunPKCS11.java > diff -r 5e403e9fa34a src/share/classes/sun/security/pkcs11/SunPKCS11.java > --- a/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu > Sep 15 15:02:05 2011 +0900 > +++ b/src/share/classes/sun/security/pkcs11/SunPKCS11.java Thu > Sep 15 12:32:03 2011 +0100 > @@ -1335,10 +1335,10 @@ public final class SunPKCS11 extends Aut > return null; > } > > - Class c = Class.forName > - (defaultHandler, > - true, > - Thread.currentThread().getContextClassLoader()); > + Class c = Class.forName > + (defaultHandler, > + true, > + Thread.currentThread().getContextClassLoader()); > return (CallbackHandler)c.newInstance(); > } > }); > > Thanks, > -Chris. Looks fine. From michael.x.mcmahon at oracle.com Thu Sep 15 13:11:51 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 15 Sep 2011 13:11:51 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110915131231.D43BB476DD@hg.openjdk.java.net> Changeset: 9281d65f911a Author: michaelm Date: 2011-09-15 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9281d65f911a 7073491: -Dsun.net.maxDatagramSockets=1 does not work correctly with system.gc() Reviewed-by: ngmr ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java Changeset: 34fc7bbbb465 Author: michaelm Date: 2011-09-15 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34fc7bbbb465 Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java From maurizio.cimadamore at oracle.com Fri Sep 16 13:17:43 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 16 Sep 2011 13:17:43 +0000 Subject: hg: jdk8/tl/langtools: 7086586: Inference producing null type argument Message-ID: <20110916131747.133E54772D@hg.openjdk.java.net> Changeset: c0835c8489b0 Author: mcimadamore Date: 2011-09-16 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0835c8489b0 7086586: Inference producing null type argument Summary: Inference should fail in 15.12.2.7 when inference variables with 'nulltype' upper bounds are found Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/generics/inference/6638712/T6638712a.out + test/tools/javac/generics/inference/7086586/T7086586.java + test/tools/javac/generics/inference/7086586/T7086586.out + test/tools/javac/generics/inference/7086586/T7086586b.java From chris.hegarty at oracle.com Fri Sep 16 22:00:12 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 16 Sep 2011 22:00:12 +0000 Subject: hg: jdk8/tl/jdk: 7090158: Networking Libraries don't build with javac -Werror Message-ID: <20110916220036.C9FC247748@hg.openjdk.java.net> Changeset: 75d763111eec Author: chegar Date: 2011-09-16 12:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75d763111eec 7090158: Networking Libraries don't build with javac -Werror Summary: Minor changes to networking java files to remove warnings Reviewed-by: chegar, weijun, hawtin Contributed-by: kurchi.subhra.hazra at oracle.com, sasha_bu at hotmail.com ! make/com/sun/net/httpserver/Makefile ! make/com/sun/net/ssl/Makefile ! make/java/net/Makefile ! make/javax/Makefile ! make/javax/others/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/SSLSecurity.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet4AddressImpl.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/Inet6AddressImpl.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/net/TransferProtocolClient.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/idn/UCharacterEnums.java ! src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java ! src/share/classes/sun/net/www/HeaderParser.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/gopher/GopherClient.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/solaris/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/solaris/classes/java/net/PlainDatagramSocketImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java From jonathan.gibbons at oracle.com Fri Sep 16 23:20:22 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 16 Sep 2011 23:20:22 +0000 Subject: hg: jdk8/tl/langtools: 7091528: javadoc attempts to parse .class files Message-ID: <20110916232027.16F6B4774C@hg.openjdk.java.net> Changeset: dea82aa3ca4f Author: jjg Date: 2011-09-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dea82aa3ca4f 7091528: javadoc attempts to parse .class files Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java + test/tools/javadoc/parser/7091528/T7091528.java + test/tools/javadoc/parser/7091528/p/C1.java + test/tools/javadoc/parser/7091528/p/q/C2.java From joe.darcy at oracle.com Sat Sep 17 01:52:18 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 16 Sep 2011 18:52:18 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" Message-ID: <4E73FD52.4020706@oracle.com> Hello. Please review the changes to address 7091682 "Move sun.misc.FpUtils code into java.lang.Math" http://cr.openjdk.java.net/~darcy/7091682.0/ As implied by the synopsis, where appropriate JDK-implementation code used to provide functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into java.lang.Math. Uses of methods available in java.lang.Math and switched to that entry point as opposed to the sun.misc one. Additionally, the sun.misc methods whose implementation was moved were also deprecated. Later in JDK 8, I will probably add some of the remaining un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath methods. Thanks, -Joe From Alan.Bateman at oracle.com Sat Sep 17 12:56:46 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 17 Sep 2011 13:56:46 +0100 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E73FD52.4020706@oracle.com> References: <4E73FD52.4020706@oracle.com> Message-ID: <4E74990E.9050304@oracle.com> joe.darcy at oracle.com wrote: > Hello. > > Please review the changes to address > > 7091682 "Move sun.misc.FpUtils code into java.lang.Math" > http://cr.openjdk.java.net/~darcy/7091682.0/ > > As implied by the synopsis, where appropriate JDK-implementation code > used to provide functionality in java.lang.Math and > java.lang.StrictMath is moved out of sun.misc.* and into > java.lang.Math. Uses of methods available in java.lang.Math and > switched to that entry point as opposed to the sun.misc one. > Additionally, the sun.misc methods whose implementation was moved were > also deprecated. > > Later in JDK 8, I will probably add some of the remaining > un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath > methods. > > Thanks, > > -Joe Looks good to me. Some of the if-then-elses are a bit inconsistent but no big deal. I did a quick search through the repository and I see that java.util.Formatter uses FpUtils.getExponent and scalb and maybe they should be changed to use Math. -Alan. From jeffhain at rocketmail.com Sat Sep 17 13:10:17 2011 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sat, 17 Sep 2011 14:10:17 +0100 (BST) Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" References: <4E73FD52.4020706@oracle.com> Message-ID: <1316265017.65246.YahooMailNeo@web29208.mail.ird.yahoo.com> Hi. There are some possible optimizations for some methods. For nextAfter(double,double) (same for float version), instead of testing NaN-ity right away, we can test most common (or at least regular) cases first: public static double nextAfter(double start, double direction) { ??? // Balancing out by branching to going-down case first, ??? // for it is heavier than going-up case (test if start is +-0.0). ??? if (start > direction) { ??????? // Going down. ??????? if (start == 0.0d) { ??????????? // start is +0.0 or -0.0 ??????????? return -Double.MIN_VALUE; ??????? } ??????? final long transducer = Double.doubleToRawLongBits(start); ??????? assert transducer != 0L; ??????? return Double.longBitsToDouble(transducer + ((transducer > 0L) ? -1L:1L)); ??? } else if (start < direction) { ??????? // Going up. ??????? // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) ??????? // then bitwise convert start to integer. ??????? final long transducer = Double.doubleToRawLongBits(start + 0.0d); ??????? return Double.longBitsToDouble(transducer + ((transducer >= 0L) ? 1L:-1L)); ??? } else if (start == direction) { ??????? return direction; ??? } else { // start and/or direction is NaN ??????? return start + direction; ??? } } Same for nextUp(double) and float version (also, testing transducer >= 0L instead of d >= 0.0D seems to help): public static double nextUp(double d) { ??? if (d < Double.POSITIVE_INFINITY) { ??????? final long transducer = Double.doubleToRawLongBits(d + 0.0D); ??????? return Double.longBitsToDouble(transducer + ((transducer >= 0L) ? 1L:-1L)); ??? } else { // d is NaN or +Infinity ??????? return d; ??? } } -Jeff ________________________________ De?: "joe.darcy at oracle.com" ??: core-libs-dev Envoy? le : Samedi 17 Septembre 2011 3h52 Objet?: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" Hello. Please review the changes to address ? 7091682 "Move sun.misc.FpUtils code into java.lang.Math" ? http://cr.openjdk.java.net/~darcy/7091682.0/ As implied by the synopsis, where appropriate JDK-implementation code used to provide functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into java.lang.Math.? Uses of methods available in java.lang.Math and switched to that entry point as opposed to the sun.misc one.? Additionally, the sun.misc methods whose implementation was moved were also deprecated. Later in JDK 8, I will probably add some of the remaining un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath methods. Thanks, -Joe From olivier.lagneau at oracle.com Wed Sep 14 12:20:39 2011 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Wed, 14 Sep 2011 14:20:39 +0200 Subject: Review Request for CR : 7050528 Improve performance of java.text.DecimalFormat.format() call stack In-Reply-To: <4E7043FC.4080705@oracle.com> References: <4E6F649C.8090005@oracle.com> <4E7043FC.4080705@oracle.com> Message-ID: <4E709C17.2000108@oracle.com> Thanks for the review and the quick reply Joe ! I agree with all your suggestions and will integrate them. For sure I did not pay enough attention to the serialization part of it. The on demand holder class idiom for 6k of "The Fast Path for double Constants" is something I had in mind but forgot to do. Thanks a lot for the patch you provided that fixes the coding style rules too. That will quicken a lot the integration of your suggestions. I will check the perf result of the new code too. Olivier. Joe Darcy said on date 9/14/2011 8:04 AM: > Hello Olivier. > > Olivier Lagneau wrote: >> Please review The implementation of a fast-path algorithm for >> optimizing the >> DecimalFormat(double, ...) call stack. >> >> The webrev is here : >> http://cr.openjdk.java.net/~alanb/7050528/webrev.01 >> >> As described in the CR evaluation and suggested fix, >> the speed-up on a micro-benchmark is ~x11 on Sparc-USIV arch and ~x10 >> on Sparc-T4. >> The footprint cost is ~6kbytes of static char array constant data to >> collect digits from integer values. >> >> New test dedicated at checking fast-path algorithm, as well as >> micro-benchmark, >> are coming soon in a subsequent webrev containing them. >> > > I have some initial comments on your changes. > > First, since the DecimalFormat class is serializable all the new > fields should be transient and the readObject method should be updated > to initialize them accordingly. However, I suggest putting the > fast-path specific data into a package private static nested class of > DecimalFormat and having a single transient pointer in DecimalFormat > to the helper object. > > Since the general contract of NumberFormat is for external > synchronization, it it not incorrect that the various new mutable > fields are not declared to be volatile (or final). > > Also in terms of organizing data, I suggest using the initialize on > demand holder class idiom for 6k of "The Fast Path for double > Constants" info. That is, create a static nested class to store the > data. This pattern ensures that the data is not loaded unnecessary > and avoids the need for synchronization when the data is accessed. > > I've attached a patch below which changes the code to more closely > follow JDK whitespace conventions. It also changes a number of > instances of > > if (condition) > foo = true; > else > foo = false; > > to > > foo = condition; > > as well as making the new fields transient (no readObject update) and > using a sun.mis.FpUtils.isFinite method. Diff below. > > Cheers, > > -Joe > > 523c523,524 > < // If fieldPosition is a DontCareFieldPosition instance we > can try to go to fast-path code. > --- > > // If fieldPosition is a DontCareFieldPosition instance we can > > // try to go to fast-path code. > 525c526,527 > < if (fieldPosition == DontCareFieldPosition.INSTANCE) > tryFastPath = true; > --- > > if (fieldPosition == DontCareFieldPosition.INSTANCE) > > tryFastPath = true; > 892c894,895 > < else if (fractionalPartAsInt != 0) boundIndex = > nbFractionalDigits; > --- > > else if (fractionalPartAsInt != 0) > > boundIndex = nbFractionalDigits; > 909c912 > < // Applies healf-even rounding rule. > --- > > // Applies half-even rounding rule. > 912c915,916 > < else return (number > perfectHalf); > --- > > else > > return (number > perfectHalf); > 916,917c920,922 > < // Returns the exact number of digits (radix 10) representing > < // the passed paramater i. Sets utility formating fields used > in the algorithm > --- > > // Returns the exact number of digits (radix 10) representing the > > // passed paramater i. Sets utility formating fields used in the > > // algorithm > 927,930c932,933 > < } > < else { > < if (i == 99) isAllNines = true; > < else isAllNines = false; > --- > > } else { > > isAllNines = (i == 99); > 934,937c937,938 > < } > < else { > < if (i == 999) isAllNines = true; > < else isAllNines = false; > --- > > } else { > > isAllNines = (i == 999); > 943,944c944 > < if (i == 9999) isAllNines = true; > < else isAllNines = false; > --- > > isAllNines = (i == 9999); > 947,950c947,948 > < } > < else { > < if (i == 99999) isAllNines = true; > < else isAllNines = false; > --- > > } else { > > isAllNines = (i == 99999); > 954,955c952 > < } > < else { > --- > > } else { > 958,959c955 > < if (i == 999999) isAllNines = true; > < else isAllNines = false; > --- > > isAllNines = (i == 999999); > 962,965c958,959 > < } > < else if (i <= 9999999) { > < if (i == 9999999) isAllNines = true; > < else isAllNines = false; > --- > > } else if (i <= 9999999) { > > isAllNines = (i == 9999999); > 968,971c962,963 > < } > < else { > < if (i == 99999999) isAllNines = true; > < else isAllNines = false; > --- > > } else { > > isAllNines = (i == 99999999); > 975,978c967,968 > < } > < else if (i <= 999999999) { > < if (i == 999999999) isAllNines = true; > < else isAllNines = false; > --- > > } else if (i <= 999999999) { > > isAllNines = (i == 999999999); > 981,982c971 > < } > < else { > --- > > } else { > 994c983,984 > < if (i == 999) isAllNines = true; > --- > > if (i == 999) > > isAllNines = true; > 996,998c986,988 > < } > < else if (i < 10) { > < if (i == 9) isAllNines = true; > --- > > } else if (i < 10) { > > if (i == 9) > > isAllNines = true; > 1000,1002c990,992 > < } > < else { > < if (i == 99) isAllNines = true; > --- > > } else { > > if (i == 99) > > isAllNines = true; > 1008,1009c998,1000 > < // Extracts and returns the 2 (Currency pattern) or 3 (Decimal > pattern) > < // digits int representing the fractional part of passed double. > --- > > // Extracts and returns the 2 (Currency pattern) or 3 (Decimal > > // pattern) digits int representing the fractional part of passed > > // double. > 1017,1018c1008 > < } > < else { > --- > > } else { > 1030d1019 > < > 1058,1060c1047,1048 > < if ((minimumIntegerDigits == 1) && > < (maximumIntegerDigits >= 10)) isFastPath = true; > < else isFastPath = false; > --- > > isFastPath = ((minimumIntegerDigits == 1) && > > (maximumIntegerDigits >= 10)); > 1067,1070c1055,1059 > < (maximumFractionDigits != 2)) isFastPath = > false; > < } > < else if ((minimumFractionDigits != 0) || > < (maximumFractionDigits != 3)) isFastPath = > false; > --- > > (maximumFractionDigits != 2)) > > isFastPath = false; > > } else if ((minimumFractionDigits != 0) || > > (maximumFractionDigits != 3)) > > isFastPath = false; > 1072,1073c1061,1062 > < } > < else isFastPath = false; > --- > > } else > > isFastPath = false; > 1121,1122c1110 > < } > < else { > --- > > } else { > 1126,1127c1114 > < } > < else if (fastPathWasOn) { > --- > > } else if (fastPathWasOn) { > 1145c1132,1133 > < if (len == 1) digitsBuffer[lowerIndex] = digit; > --- > > if (len == 1) > > digitsBuffer[lowerIndex] = digit; > 1154c1142,1143 > < if (--upperIndex > lowerIndex) > digitsBuffer[upperIndex] = digit; > --- > > if (--upperIndex > lowerIndex) > > digitsBuffer[upperIndex] = digit; > 1165c1154,1155 > < else suffix = charsPositiveSuffix; > --- > > else > > suffix = charsPositiveSuffix; > 1169c1159,1160 > < if (len == 0) return; > --- > > if (len == 0) > > return; > 1181,1184c1172,1177 > < if (len > 2) internalChars[dstLower] = suffix[1]; > < if (len == 4) internalChars[dstUpper] = suffix[2]; > < } > < else System.arraycopy(suffix, 0, internalChars, startIndex, > len); > --- > > if (len > 2) > > internalChars[dstLower] = suffix[1]; > > if (len == 4) > > internalChars[dstUpper] = suffix[2]; > > } else > > System.arraycopy(suffix, 0, internalChars, startIndex, > len); > 1192c1185,1186 > < // We localize digits only, taking into account > currency/decimal fractional case > --- > > // We localize digits only, taking into account > > // currency/decimal fractional case > 1199,1201c1193,1195 > < } > < else { > < // Cursor char is decimal separator or grouping > char. Just reinit counter. > --- > > } else { > > // Cursor char is decimal separator or grouping > > // char. Just reinit counter. > 1212c1206,1207 > < if (!toBeRounded) fillDigit = '9'; > --- > > if (!toBeRounded) > > fillDigit = '9'; > 1234,1235c1229,1230 > < } > < else break; > --- > > } else > > break; > 1239,1240c1234,1237 > < if (!toBeRounded || isCurrencyFormat) lastUsedIndex += > fractionalLength; > < else lastUsedIndex--; // fractional part absent > --- > > if (!toBeRounded || isCurrencyFormat) > > lastUsedIndex += fractionalLength; > > else > > lastUsedIndex--; // fractional part absent > 1269,1270c1266,1267 > < } > < else digitsBuffer[index] = DigitTens1000[number]; > --- > > } else > > digitsBuffer[index] = DigitTens1000[number]; > 1289,1290c1286 > < } > < else { > --- > > } else { > 1292c1288,1289 > < if (number == 0) index -= 4; > --- > > if (number == 0) > > index -= 4; > 1302,1303c1299 > < } > < else { > --- > > } else { > 1352,1353c1348 > < } > < else { > --- > > } else { > 1368,1369c1363 > < } > < else { > --- > > } else { > 1373,1374c1367 > < } > < else { > --- > > } else { > 1386c1379,1380 > < else formatAllNinesCase(internalChars, startIndex, > --- > > else { > > formatAllNinesCase(internalChars, startIndex, > 1388a1383 > > } > 1391c1386,1387 > < if (zeroDelta != 0) localizeDigits(internalChars, startIndex); > --- > > if (zeroDelta != 0) > > localizeDigits(internalChars, startIndex); > 1394c1390,1391 > < if (isSuffixPresent) appendSuffix(negative, internalChars); > --- > > if (isSuffixPresent) > > appendSuffix(negative, internalChars); > 1411c1408,1409 > < if (fastPathCheckNeeded) checkAndSetFastPathStatus(); > --- > > if (fastPathCheckNeeded) > > checkAndSetFastPathStatus(); > 1414,1416c1412,1413 > < if (!Double.isNaN(number) && > < !Double.isInfinite(number)) { > < > --- > > // If finite > > if (sun.misc.FpUtils.isFinite(number)) { > 1427,1428c1424 > < } > < else if (number < 0.0) { // 2 tests for negative > doubles > --- > > } else if (number < 0.0) { // 2 tests for negative > doubles > 1436,1437c1432 > < } > < else if ( 1/number > 0.0) { // 3 tests for positive > zero. Not frequent. > --- > > } else if ( 1/number > 0.0) { // 3 tests for > positive zero. Not frequent. > 1442,1443c1437 > < } > < else { // 4 tests for negative zero (hopefully very > rare) > --- > > } else { // 4 tests for negative zero (hopefully > very rare) > 3828c3822 > < private boolean isAllNines = false; > --- > > private transient boolean isAllNines = false; > 3831c3825 > < private double remainingFractionalPart = 0.0d; > --- > > private transient double remainingFractionalPart = 0.0d; > 3834c3828 > < private int lastUsedIndex = 0; > --- > > private transient int lastUsedIndex = 0; > 3837c3831 > < private int nbGroupsNeeded = 0; > --- > > private transient int nbGroupsNeeded = 0; > 3842c3836 > < private boolean isFastPath = false; > --- > > private transient boolean isFastPath = false; > 3845c3839 > < private boolean fastPathCheckNeeded = true; > --- > > private transient boolean fastPathCheckNeeded = true; > 3848,3849c3842,3843 > < private char[] positiveFastPathContainer; > < private char[] negativeFastPathContainer; > --- > > private transient char[] positiveFastPathContainer; > > private transient char[] negativeFastPathContainer; > 3852,3853c3846,3847 > < private double[] safeMinusRoundingBounds = null; > < private double[] safeMajorRoundingBounds = null; > --- > > private transient double[] safeMinusRoundingBounds = null; > > private transient double[] safeMajorRoundingBounds = null; > 3856,3858c3850,3852 > < private boolean isSuffixPresent; > < private char[] charsPositiveSuffix; > < private char[] charsNegativeSuffix; > --- > > private transient boolean isSuffixPresent; > > private transient char[] charsPositiveSuffix; > > private transient char[] charsNegativeSuffix; > 3861c3855 > < private int zeroDelta; > --- > > private transient int zeroDelta; > 3864c3858 > < private char groupingChar; > --- > > private transient char groupingChar; > 3867c3861 > < private char decimalSeparatorChar; > --- > > private transient char decimalSeparatorChar; > 3921,3922c3915,3918 > < if (digitOne == '9') digitOne = '0'; > < else digitOne++; > --- > > if (digitOne == '9') > > digitOne = '0'; > > else > > digitOne++; > 3927,3928c3923,3926 > < if (digitTen == '9') digitTen = '0'; > < else digitTen++; > --- > > if (digitTen == '9') > > digitTen = '0'; > > else > > digitTen++; > From mala.bankal at oracle.com Thu Sep 15 05:37:40 2011 From: mala.bankal at oracle.com (mala.bankal at oracle.com) Date: Thu, 15 Sep 2011 05:37:40 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110915053826.6EAC8476C5@hg.openjdk.java.net> Changeset: 52bc200b14e5 Author: mbankal Date: 2011-09-14 21:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52bc200b14e5 7049963: DISTINGUISHED NAMES FOR CERT ARE ESCAPED IN JROCKIT 1.6(NOT COMPATIBLE WITH JROC Reviewed-by: mullan ! src/share/classes/sun/security/x509/AVA.java Changeset: 1260be51581f Author: mbankal Date: 2011-09-14 22:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1260be51581f Merge From alan.bateman at oracle.com Sun Sep 18 11:34:53 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 18 Sep 2011 11:34:53 +0000 Subject: hg: jdk8/tl/jdk: 7091935: (fs) Polling based WatchService not used on Linux Message-ID: <20110918113517.49A1947797@hg.openjdk.java.net> Changeset: ccf2a19d7d87 Author: alanb Date: 2011-09-18 12:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccf2a19d7d87 7091935: (fs) Polling based WatchService not used on Linux Reviewed-by: forax ! make/java/nio/Makefile From mike.duigou at oracle.com Sun Sep 18 20:24:59 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 18 Sep 2011 13:24:59 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E73FD52.4020706@oracle.com> References: <4E73FD52.4020706@oracle.com> Message-ID: I am curious why some of the tests still refer to FpUtils. For example: Log10Tests.java: 156 up = Math.nextUp(1.0); 157 down = FpUtils.nextDown(1.0); Would it be possible to further reduce or eliminate the references to FpUtils from the tests? Mike On Sep 16 2011, at 18:52 , joe.darcy at oracle.com wrote: > Hello. > > Please review the changes to address > > 7091682 "Move sun.misc.FpUtils code into java.lang.Math" > http://cr.openjdk.java.net/~darcy/7091682.0/ > > As implied by the synopsis, where appropriate JDK-implementation code used to provide functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into java.lang.Math. Uses of methods available in java.lang.Math and switched to that entry point as opposed to the sun.misc one. Additionally, the sun.misc methods whose implementation was moved were also deprecated. > > Later in JDK 8, I will probably add some of the remaining un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath methods. > > Thanks, > > -Joe From joe.darcy at oracle.com Mon Sep 19 01:07:17 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 18 Sep 2011 18:07:17 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: References: <4E73FD52.4020706@oracle.com> Message-ID: <4E7695C5.3050002@oracle.com> Mike Duigou wrote: > I am curious why some of the tests still refer to FpUtils. For example: > > Log10Tests.java: > 156 up = Math.nextUp(1.0); > 157 down = FpUtils.nextDown(1.0); > > Would it be possible to further reduce or eliminate the references to FpUtils from the tests? > The nextDown method is in FpUtils, but not currently in java.lang.Math. Assuming nextDown is added to Math, those references should be eliminated too. -Joe > Mike > > On Sep 16 2011, at 18:52 , joe.darcy at oracle.com wrote: > > >> Hello. >> >> Please review the changes to address >> >> 7091682 "Move sun.misc.FpUtils code into java.lang.Math" >> http://cr.openjdk.java.net/~darcy/7091682.0/ >> >> As implied by the synopsis, where appropriate JDK-implementation code used to provide functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into java.lang.Math. Uses of methods available in java.lang.Math and switched to that entry point as opposed to the sun.misc one. Additionally, the sun.misc methods whose implementation was moved were also deprecated. >> >> Later in JDK 8, I will probably add some of the remaining un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath methods. >> >> Thanks, >> >> -Joe >> > > From joe.darcy at oracle.com Mon Sep 19 01:10:29 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 18 Sep 2011 18:10:29 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E74990E.9050304@oracle.com> References: <4E73FD52.4020706@oracle.com> <4E74990E.9050304@oracle.com> Message-ID: <4E769685.9090503@oracle.com> Alan Bateman wrote: > joe.darcy at oracle.com wrote: >> Hello. >> >> Please review the changes to address >> >> 7091682 "Move sun.misc.FpUtils code into java.lang.Math" >> http://cr.openjdk.java.net/~darcy/7091682.0/ >> >> As implied by the synopsis, where appropriate JDK-implementation code >> used to provide functionality in java.lang.Math and >> java.lang.StrictMath is moved out of sun.misc.* and into >> java.lang.Math. Uses of methods available in java.lang.Math and >> switched to that entry point as opposed to the sun.misc one. >> Additionally, the sun.misc methods whose implementation was moved >> were also deprecated. >> >> Later in JDK 8, I will probably add some of the remaining >> un-deprecated methods in sun.misc.FpUtils as >> java.lang.Math/StrictMath methods. >> >> Thanks, >> >> -Joe > Looks good to me. Some of the if-then-elses are a bit inconsistent but > no big deal. I did a quick search through the repository and I see > that java.util.Formatter uses FpUtils.getExponent and scalb and maybe > they should be changed to use Math. > Thanks for noticing that Alan; I'm remove some additional uses of FpUtils in Float, Double, and Formatter before the push. Cheers, -Joe From joe.darcy at oracle.com Mon Sep 19 01:14:26 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 19 Sep 2011 01:14:26 +0000 Subject: hg: jdk8/tl/jdk: 7091682: Move sun.misc.FpUtils code into java.lang.Math Message-ID: <20110919011436.85925477B7@hg.openjdk.java.net> Changeset: 418628a08ae7 Author: darcy Date: 2011-09-18 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/418628a08ae7 7091682: Move sun.misc.FpUtils code into java.lang.Math Reviewed-by: alanb ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ToHexString.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java From joe.darcy at oracle.com Mon Sep 19 01:15:12 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 18 Sep 2011 18:15:12 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <1316265017.65246.YahooMailNeo@web29208.mail.ird.yahoo.com> References: <4E73FD52.4020706@oracle.com> <1316265017.65246.YahooMailNeo@web29208.mail.ird.yahoo.com> Message-ID: <4E7697A0.9010206@oracle.com> Hi Jeff. I'll consider that for some possible future work. Thanks, -Joe Jeff Hain wrote: > Hi. > There are some possible optimizations for some methods. > > For nextAfter(double,double) (same for float version), instead of > testing NaN-ity right away, > we can test most common (or at least regular) cases first: > public static double nextAfter(double start, double direction) { > // Balancing out by branching to going-down case first, > // for it is heavier than going-up case (test if start is +-0.0). > if (start > direction) { > // Going down. > if (start == 0.0d) { > // start is +0.0 or -0.0 > return -Double.MIN_VALUE; > } > final long transducer = Double.doubleToRawLongBits(start); > assert transducer != 0L; > return Double.longBitsToDouble(transducer + ((transducer > 0L) > ? -1L:1L)); > } else if (start < direction) { > // Going up. > // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) > // then bitwise convert start to integer. > final long transducer = Double.doubleToRawLongBits(start + 0.0d); > return Double.longBitsToDouble(transducer + ((transducer >= > 0L) ? 1L:-1L)); > } else if (start == direction) { > return direction; > } else { // start and/or direction is NaN > return start + direction; > } > } > > Same for nextUp(double) and float version (also, testing transducer >= 0L > instead of d >= 0.0D seems to help): > public static double nextUp(double d) { > if (d < Double.POSITIVE_INFINITY) { > final long transducer = Double.doubleToRawLongBits(d + 0.0D); > return Double.longBitsToDouble(transducer + ((transducer >= > 0L) ? 1L:-1L)); > } else { // d is NaN or +Infinity > return d; > } > } > > -Jeff > > ------------------------------------------------------------------------ > *De :* "joe.darcy at oracle.com" > *? :* core-libs-dev > *Envoy? le :* Samedi 17 Septembre 2011 3h52 > *Objet :* JDK 8 code review request for 7091682 "Move sun.misc.FpUtils > code into java.lang.Math" > > Hello. > > Please review the changes to address > > 7091682 "Move sun.misc.FpUtils code into java.lang.Math" > http://cr.openjdk.java.net/~darcy/7091682.0/ > > > As implied by the synopsis, where appropriate JDK-implementation code > used to provide functionality in java.lang.Math and > java.lang.StrictMath is moved out of sun.misc.* and into > java.lang.Math. Uses of methods available in java.lang.Math and > switched to that entry point as opposed to the sun.misc one. > Additionally, the sun.misc methods whose implementation was moved were > also deprecated. > > Later in JDK 8, I will probably add some of the remaining > un-deprecated methods in sun.misc.FpUtils as java.lang.Math/StrictMath > methods. > > Thanks, > > -Joe > > From David.Holmes at oracle.com Mon Sep 19 05:22:34 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 19 Sep 2011 15:22:34 +1000 Subject: Request for review: 7012206 Message-ID: <4E76D19A.4080008@oracle.com> This a change to a bunch of serviceability tests (shell scripts that launch the various j* tools (jps, jstatd, jstack etc)) that I'd like to push through the TL JDK repo. The changes were done by Carlos Lucasius but I'm acting as his "sponsor" for getting these pushed. webrev: http://cr.openjdk.java.net/~dholmes/7012206/webrev/ Summary: for correct operation the tools and/or the VM they target must be running with UsePerfData enabled. This VM option is enabled in Java SE by default, but is disabled in Java SE Embedded by default. To allow the tests to be used regardless of the UsePerfdata setting they are augmented to explicitly turn it on. There has been some prior internal debate around how "best" to deal with this issue and the resulting changes, while somewhat repetitive, are the simplest approach to take. There is one test - jps/jps-Vvml_2.sh - that can not pass with such a fix because it is actually trying to test the jps output when no arguments (VM or application) are passed to the target VM. So for that test I've just added a comment. Thanks, David From Alan.Bateman at oracle.com Mon Sep 19 08:57:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Sep 2011 09:57:45 +0100 Subject: Request for review: 7012206 In-Reply-To: <4E76D19A.4080008@oracle.com> References: <4E76D19A.4080008@oracle.com> Message-ID: <4E770409.8010209@oracle.com> David Holmes wrote: > This a change to a bunch of serviceability tests (shell scripts that > launch the various j* tools (jps, jstatd, jstack etc)) that I'd like > to push through the TL JDK repo. > > The changes were done by Carlos Lucasius but I'm acting as his > "sponsor" for getting these pushed. > > webrev: http://cr.openjdk.java.net/~dholmes/7012206/webrev/ > > Summary: for correct operation the tools and/or the VM they target > must be running with UsePerfData enabled. This VM option is enabled in > Java SE by default, but is disabled in Java SE Embedded by default. To > allow the tests to be used regardless of the UsePerfdata setting they > are augmented to explicitly turn it on. > > There has been some prior internal debate around how "best" to deal > with this issue and the resulting changes, while somewhat repetitive, > are the simplest approach to take. > > There is one test - jps/jps-Vvml_2.sh - that can not pass with such a > fix because it is actually trying to test the jps output when no > arguments (VM or application) are passed to the target VM. So for that > test I've just added a comment. This one reminds me that we need to go over all our shell tests so that they pass $TESTVMOPTS through to all VMs that they create. Otherwise we aren't always testing what we think we are testing. The changes in the webrev look fine to me but I would have expected to see tests other than the jvmstat stats, for example the tests in com/sun/tools/attach and sun/management/jmxremote/bootstrap. -Alan. From michael.x.mcmahon at oracle.com Mon Sep 19 14:21:04 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 19 Sep 2011 14:21:04 +0000 Subject: hg: jdk8/tl/jdk: 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Message-ID: <20110919142127.74370477D3@hg.openjdk.java.net> Changeset: e3d78fe803d4 Author: michaelm Date: 2011-09-19 15:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3d78fe803d4 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 Reviewed-by: chegar, alanb ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java From joe.darcy at oracle.com Mon Sep 19 16:48:28 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 19 Sep 2011 09:48:28 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E7697A0.9010206@oracle.com> References: <4E73FD52.4020706@oracle.com> <1316265017.65246.YahooMailNeo@web29208.mail.ird.yahoo.com> <4E7697A0.9010206@oracle.com> Message-ID: <4E77725C.8060807@oracle.com> PS I've added your comment to bug 6667086 "Double.doubleToLongBits(final double value) contains inefficient test for NaN." -Joe On 9/18/2011 6:15 PM, Joe Darcy wrote: > Hi Jeff. > > I'll consider that for some possible future work. > > Thanks, > > -Joe > > Jeff Hain wrote: >> Hi. >> There are some possible optimizations for some methods. >> >> For nextAfter(double,double) (same for float version), instead of >> testing NaN-ity right away, >> we can test most common (or at least regular) cases first: >> public static double nextAfter(double start, double direction) { >> // Balancing out by branching to going-down case first, >> // for it is heavier than going-up case (test if start is +-0.0). >> if (start > direction) { >> // Going down. >> if (start == 0.0d) { >> // start is +0.0 or -0.0 >> return -Double.MIN_VALUE; >> } >> final long transducer = Double.doubleToRawLongBits(start); >> assert transducer != 0L; >> return Double.longBitsToDouble(transducer + ((transducer > >> 0L) ? -1L:1L)); >> } else if (start < direction) { >> // Going up. >> // Add +0.0 to get rid of a -0.0 (+0.0 + -0.0 => +0.0) >> // then bitwise convert start to integer. >> final long transducer = Double.doubleToRawLongBits(start + >> 0.0d); >> return Double.longBitsToDouble(transducer + ((transducer >= >> 0L) ? 1L:-1L)); >> } else if (start == direction) { >> return direction; >> } else { // start and/or direction is NaN >> return start + direction; >> } >> } >> >> Same for nextUp(double) and float version (also, testing transducer >> >= 0L >> instead of d >= 0.0D seems to help): >> public static double nextUp(double d) { >> if (d < Double.POSITIVE_INFINITY) { >> final long transducer = Double.doubleToRawLongBits(d + 0.0D); >> return Double.longBitsToDouble(transducer + ((transducer >= >> 0L) ? 1L:-1L)); >> } else { // d is NaN or +Infinity >> return d; >> } >> } >> >> -Jeff >> >> ------------------------------------------------------------------------ >> *De :* "joe.darcy at oracle.com" >> *? :* core-libs-dev >> *Envoy? le :* Samedi 17 Septembre 2011 3h52 >> *Objet :* JDK 8 code review request for 7091682 "Move >> sun.misc.FpUtils code into java.lang.Math" >> >> Hello. >> >> Please review the changes to address >> >> 7091682 "Move sun.misc.FpUtils code into java.lang.Math" >> http://cr.openjdk.java.net/~darcy/7091682.0/ >> >> >> As implied by the synopsis, where appropriate JDK-implementation code >> used to provide functionality in java.lang.Math and >> java.lang.StrictMath is moved out of sun.misc.* and into >> java.lang.Math. Uses of methods available in java.lang.Math and >> switched to that entry point as opposed to the sun.misc one. >> Additionally, the sun.misc methods whose implementation was moved >> were also deprecated. >> >> Later in JDK 8, I will probably add some of the remaining >> un-deprecated methods in sun.misc.FpUtils as >> java.lang.Math/StrictMath methods. >> >> Thanks, >> >> -Joe >> >> > From Ulf.Zibis at gmx.de Mon Sep 19 17:20:32 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 19 Sep 2011 19:20:32 +0200 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E73FD52.4020706@oracle.com> References: <4E73FD52.4020706@oracle.com> Message-ID: <4E7779E0.2070901@gmx.de> Without a deeper look, I discovered several ternary operators without spacing. For better readability, it would be nice to insert some spaces. :-) -Ulf Am 17.09.2011 03:52, schrieb joe.darcy at oracle.com: > Hello. > > Please review the changes to address > > 7091682 "Move sun.misc.FpUtils code into java.lang.Math" > http://cr.openjdk.java.net/~darcy/7091682.0/ > > As implied by the synopsis, where appropriate JDK-implementation code used to provide > functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into > java.lang.Math. Uses of methods available in java.lang.Math and switched to that entry point as > opposed to the sun.misc one. Additionally, the sun.misc methods whose implementation was moved > were also deprecated. > > Later in JDK 8, I will probably add some of the remaining un-deprecated methods in > sun.misc.FpUtils as java.lang.Math/StrictMath methods. > > Thanks, > > -Joe > From xueming.shen at oracle.com Mon Sep 19 20:21:33 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 19 Sep 2011 13:21:33 -0700 Subject: Codereview request for 7082884: Incorrect UTF8 conversion for sequence ED 31 Message-ID: <4E77A44D.8050706@oracle.com> Hi, Unicode Standard added "Addition Constraints on conversion of ill-formed UTF-8" in version 5.1 [1] and updated in 6.0 again with further "clarification" [2] regarding how a "conformance" implementation should handle ill-formed UTF-8 byte sequence. Basically it says (1) the conversion process should not interprets any ill-formed code unit sequence *(2) such process must not treat any adjacent well-formed code unit sequences as being part of those ill-formed code unit sequences (3) and recommend a "best practice" of "maximal valid subpart" for replacement The new UTF-8 charset implementation we put in JDK7 (and back-ported to previous release since then) follows the new constraints in most cases. Except 2 corner cases (we are aware of so far for now"). 7082884 is one of them. The current implementation decode new String(new byte[]{(byte)0xed, 31}, "UTF8") into one single char "\ufffd". while it should be "\ufffd\u001f" instead, according to the new constraints (the first 0xed is ill-formed, and the second 0x1f is still valid non-ill-formed, so it should not be consumed, even the first byte 0xed is a leading byte a three-byte utf-8 byte sequence). The reason I called it a "corner case" is because then new UTF-8 implementation handles it correctly in most cases, for example new String(new byte[]{(byte)0xed, 31, 'a'}, "UTF8"); does return the expected result "\ufffd\u001f\u0061" The corner case here is that the 0xed is the leading byte of a three-byte utf-8 byte sequence, but we actually only 2 bytes total in pipe. The current UTF-8 decoder implementation will not even look into the following bytes when it has a leading byte of a 3-byte utf-8 sequence and it has less than 3 bytes to work on. In this case it simply returns "underflow", means "I need more bytes". Unfortunately its upper level implementation, CharsetDecoder, will simply treat this "underflow" status as a malformed byte sequence of "2" (it's reasonable for CharsetDecoder to make such a decision as well, see the decoder does not have enough bytes to handle these 2 bytes, and we don't have any more bytes following, so the rest are all "malformed"). The fix is to further look into the following bytes when we have a leading byte, even don't have enough bytes to complete the conversion. The webrev is at http://cr.openjdk.java.net/~sherman/7082884/webrev Another corner case is how to deal with the old 5-6 bytes byte sequence, such as "fc 80 80 8f bf bf", we are now treating them as 1 malformed utf-8 byte sequence, so any of these 5-6 bytes "old" formed will be treated one malformed character and then replaced by one "\ufffd". But according to the new "best practice" recommendation, it probably should be replaced by 6 \ufffd. if I understand the recommendation correctly. Personally I feel the existing implementation is a more reasonable approach, opinion? Thanks -Sherman [1] http://www.unicode.org/versions/Unicode5.1.0/#Notable_Changes [2] http://www.unicode.org/versions/Unicode6.0.0/#Conformance_Changes [3] http://blogs.oracle.com/xuemingshen/entry/the_big_overhaul_of_java From john.r.rose at oracle.com Mon Sep 19 21:58:15 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 14:58:15 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow Message-ID: http://cr.openjdk.java.net/~jrose/7030453/webrev.00 The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. - It relies on internal details of WeakHashMap to avoid other race conditions. The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). -- John From weijun.wang at oracle.com Tue Sep 20 04:41:07 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 20 Sep 2011 04:41:07 +0000 Subject: hg: jdk8/tl/jdk: 7091290: fails to build jdk8 b05 Embedded build Message-ID: <20110920044124.1EEB7477FF@hg.openjdk.java.net> Changeset: 8fe6d94683af Author: weijun Date: 2011-09-20 12:40 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fe6d94683af 7091290: fails to build jdk8 b05 Embedded build Reviewed-by: xuelei, dholmes ! src/share/classes/org/ietf/jgss/Oid.java From David.Holmes at oracle.com Tue Sep 20 05:05:28 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 20 Sep 2011 15:05:28 +1000 Subject: Request for review: 7012206 In-Reply-To: <4E770409.8010209@oracle.com> References: <4E76D19A.4080008@oracle.com> <4E770409.8010209@oracle.com> Message-ID: <4E781F18.6060703@oracle.com> Thanks Alan. Other failures haven't shown up thus far so for now we'll just address these ones (it improves the pass rate somewhat :) ). Could I get a second review from someone in serviceability? Thanks, David On 19/09/2011 6:57 PM, Alan Bateman wrote: > David Holmes wrote: >> This a change to a bunch of serviceability tests (shell scripts that >> launch the various j* tools (jps, jstatd, jstack etc)) that I'd like to >> push through the TL JDK repo. >> >> The changes were done by Carlos Lucasius but I'm acting as his "sponsor" >> for getting these pushed. >> >> webrev: http://cr.openjdk.java.net/~dholmes/7012206/webrev/ >> >> Summary: for correct operation the tools and/or the VM they target must be >> running with UsePerfData enabled. This VM option is enabled in Java SE by >> default, but is disabled in Java SE Embedded by default. To allow the >> tests to be used regardless of the UsePerfdata setting they are augmented >> to explicitly turn it on. >> >> There has been some prior internal debate around how "best" to deal with >> this issue and the resulting changes, while somewhat repetitive, are the >> simplest approach to take. >> >> There is one test - jps/jps-Vvml_2.sh - that can not pass with such a fix >> because it is actually trying to test the jps output when no arguments (VM >> or application) are passed to the target VM. So for that test I've just >> added a comment. > This one reminds me that we need to go over all our shell tests so that they > pass $TESTVMOPTS through to all VMs that they create. Otherwise we aren't > always testing what we think we are testing. > > The changes in the webrev look fine to me but I would have expected to see > tests other than the jvmstat stats, for example the tests in > com/sun/tools/attach and sun/management/jmxremote/bootstrap. > > -Alan. From john.r.rose at oracle.com Tue Sep 20 05:35:06 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 19 Sep 2011 22:35:06 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote: > FYI, There's one, java.lang.Integer's cache size is tunable via JVM command line flag -XX:AutoBoxCacheMax, which in turn sets Java system property "java.lang.Integer.IntegerCache.high", and affects the Integer cache size. But that's probably a special case anyway. Thanks for the reminder, Kris. -- John From forax at univ-mlv.fr Tue Sep 20 09:42:09 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 20 Sep 2011 11:42:09 +0200 Subject: hg: jdk8/tl/jdk: 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 In-Reply-To: <20110919142127.74370477D3@hg.openjdk.java.net> References: <20110919142127.74370477D3@hg.openjdk.java.net> Message-ID: <4E785FF1.3090803@univ-mlv.fr> On 09/19/2011 04:21 PM, michael.x.mcmahon at oracle.com wrote: > Changeset: e3d78fe803d4 > Author: michaelm > Date: 2011-09-19 15:14 +0100 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3d78fe803d4 > > 7091369: DatagramSocket/Limit.java failing on 8 and 7u2 > Reviewed-by: chegar, alanb > > ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java > Hi Michael, I'm not a big fan of this code. I don't see why you're using the precise-rethrow feature here. I think the code should be: try { super.create(); } catch (SocketException e) { fd1 = null; throw e; } R?mi From kelly.ohair at oracle.com Tue Sep 20 14:36:29 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 20 Sep 2011 07:36:29 -0700 Subject: Request for review: 7012206 In-Reply-To: <4E781F18.6060703@oracle.com> References: <4E76D19A.4080008@oracle.com> <4E770409.8010209@oracle.com> <4E781F18.6060703@oracle.com> Message-ID: <79A04E39-CDA7-4F6A-87E0-F245F2508A4D@oracle.com> On Sep 19, 2011, at 10:05 PM, David Holmes wrote: > Thanks Alan. Other failures haven't shown up thus far so for now we'll just address these ones (it improves the pass rate somewhat :) ). > > Could I get a second review from someone in serviceability? They look fine to me. -kto > > Thanks, > David > > On 19/09/2011 6:57 PM, Alan Bateman wrote: >> David Holmes wrote: >>> This a change to a bunch of serviceability tests (shell scripts that >>> launch the various j* tools (jps, jstatd, jstack etc)) that I'd like to >>> push through the TL JDK repo. >>> >>> The changes were done by Carlos Lucasius but I'm acting as his "sponsor" >>> for getting these pushed. >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/7012206/webrev/ >>> >>> Summary: for correct operation the tools and/or the VM they target must be >>> running with UsePerfData enabled. This VM option is enabled in Java SE by >>> default, but is disabled in Java SE Embedded by default. To allow the >>> tests to be used regardless of the UsePerfdata setting they are augmented >>> to explicitly turn it on. >>> >>> There has been some prior internal debate around how "best" to deal with >>> this issue and the resulting changes, while somewhat repetitive, are the >>> simplest approach to take. >>> >>> There is one test - jps/jps-Vvml_2.sh - that can not pass with such a fix >>> because it is actually trying to test the jps output when no arguments (VM >>> or application) are passed to the target VM. So for that test I've just >>> added a comment. >> This one reminds me that we need to go over all our shell tests so that they >> pass $TESTVMOPTS through to all VMs that they create. Otherwise we aren't >> always testing what we think we are testing. >> >> The changes in the webrev look fine to me but I would have expected to see >> tests other than the jvmstat stats, for example the tests in >> com/sun/tools/attach and sun/management/jmxremote/bootstrap. >> >> -Alan. From aleksey.shipilev at gmail.com Tue Sep 20 16:29:10 2011 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Tue, 20 Sep 2011 20:29:10 +0400 Subject: DelayQueue is not Serializable? Message-ID: Hi, I've been stumbled upon this for a bit. Is there any specific reason DelayQueue is not serializable? Or is it an API bug? The backing PriorityQueue *is* serializable. Thanks, Aleksey. From dl at cs.oswego.edu Tue Sep 20 18:34:13 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 20 Sep 2011 14:34:13 -0400 Subject: DelayQueue is not Serializable? In-Reply-To: References: Message-ID: <4E78DCA5.3000008@cs.oswego.edu> On 09/20/11 12:29, Aleksey Shipilev wrote: > Hi, > > I've been stumbled upon this for a bit. > Is there any specific reason DelayQueue is not serializable? Or is it > an API bug? > The backing PriorityQueue *is* serializable. > It was a deliberate decision. DelayQueues use relative times, so the delays don't make sense when deserialized at an arbitrary time. And there's no way to guarantee a correct clock resync to re-normalize. Plus, no one has ever complained about this, so we haven't ever revisited it. -Doug From jonathan.gibbons at oracle.com Tue Sep 20 19:13:08 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Sep 2011 19:13:08 +0000 Subject: hg: jdk8/tl/langtools: 7030473: Remove dead field JCCompilationUnit.flags Message-ID: <20110920191312.D72F747823@hg.openjdk.java.net> Changeset: ac964af3b5e7 Author: jjg Date: 2011-09-20 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac964af3b5e7 7030473: Remove dead field JCCompilationUnit.flags Reviewed-by: dlsmith ! src/share/classes/com/sun/tools/javac/tree/JCTree.java From mike.duigou at oracle.com Tue Sep 20 19:32:24 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 20 Sep 2011 19:32:24 +0000 Subject: hg: jdk8/tl/jdk: 7074264: Switches to packages tree view and adds unit tests to sources Message-ID: <20110920193241.CA88B47826@hg.openjdk.java.net> Changeset: c77b41652266 Author: mduigou Date: 2011-09-20 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c77b41652266 7074264: Switches to packages tree view and adds unit tests to sources Reviewed-by: igor ! make/netbeans/README ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/j2se/nbproject/project.xml From mike.duigou at oracle.com Tue Sep 20 20:11:36 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 Sep 2011 13:11:36 -0700 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers Message-ID: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> Hello all; Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ The webrev combines two issues: 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes 7088952: Add "BYTES" constant to primitive wrapper classes Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. Thanks, Mike From christian.thalinger at oracle.com Tue Sep 20 08:02:49 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Sep 2011 10:02:49 +0200 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: On Sep 19, 2011, at 11:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 src/share/classes/java/lang/ClassValue.java: 233 /** Value stream for for hashCodeForCache. See similar structure in ThreadLocal. */ Two for's. 578 * from the ehad of a non-null run, which would allow them "ehad"? Otherwise I think this looks good. -- Christian > > The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways: > - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow. > - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered. > - It relies on internal details of WeakHashMap to avoid other race conditions. > > The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups. It is more correct and scalable. > > The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads. Experience with real workloads will probably lead to further modifications (under new Change Requests). I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back. > > The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published. I removed it because it is a false fix for user-caused race conditions. (False because it has the desired effect only on some platforms.) I think it is better to put that issue back onto the user. We still need a memory fence API to give users the right hook for such problems. > > There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java). > > Although this class is in java.lang, it is part of JSR 292. Therefore the review comments will be collected in mlvm-dev. The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang). > > -- John From john.r.rose at oracle.com Tue Sep 20 23:10:14 2011 From: john.r.rose at oracle.com (John Rose) Date: Tue, 20 Sep 2011 16:10:14 -0700 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: References: Message-ID: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> On Sep 19, 2011, at 2:58 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/7030453/webrev.00 After some comments from David Holmes (thanks David!) I added internal comments about race conditions. I refreshed the webrev with the additional comments. I also changed one variable to be volatile, with a paragraph of comments explaining why. (The change to volatile will inhibit CSE of ClassValue.get calls, but I think such CSE was unlikely anyway. There should be no other performance effects.) -- John From joe.darcy at oracle.com Tue Sep 20 23:46:12 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 20 Sep 2011 16:46:12 -0700 Subject: JDK 8 code review request for 6268216 "Boolean.getBoolean() throws SecurityException" Message-ID: <4E7925C4.9060509@oracle.com> Hello. Please review this simple fix to add some informative text detailing when an unchecked security exception can be thrown: 6268216 "Boolean.getBoolean() throws SecurityException" http://cr.openjdk.java.net/~darcy/6268216.0/ Diff below. Thanks, -Joe --- old/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:18.000000000 -0700 +++ new/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:17.000000000 -0700 @@ -229,6 +229,8 @@ * * @param name the system property name. * @return the {@code boolean} value of the system property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see java.lang.System#getProperty(java.lang.String) * @see java.lang.System#getProperty(java.lang.String, java.lang.String) */ @@ -236,8 +238,7 @@ boolean result = false; try { result = toBoolean(System.getProperty(name)); - } catch (IllegalArgumentException e) { - } catch (NullPointerException e) { + } catch (IllegalArgumentException | NullPointerException e) { } return result; } --- old/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 +++ new/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 @@ -797,6 +797,8 @@ * * @param nm property name. * @return the {@code Integer} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see java.lang.System#getProperty(java.lang.String) * @see java.lang.System#getProperty(java.lang.String, java.lang.String) */ @@ -841,6 +843,8 @@ * @param nm property name. * @param val default value. * @return the {@code Integer} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see java.lang.System#getProperty(java.lang.String) * @see java.lang.System#getProperty(java.lang.String, java.lang.String) */ @@ -881,6 +885,8 @@ * @param nm property name. * @param val default value. * @return the {@code Integer} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see System#getProperty(java.lang.String) * @see System#getProperty(java.lang.String, java.lang.String) */ --- old/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 +++ new/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 @@ -827,6 +827,8 @@ * * @param nm property name. * @return the {@code Long} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see java.lang.System#getProperty(java.lang.String) * @see java.lang.System#getProperty(java.lang.String, java.lang.String) */ @@ -870,6 +872,8 @@ * @param nm property name. * @param val default value. * @return the {@code Long} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see java.lang.System#getProperty(java.lang.String) * @see java.lang.System#getProperty(java.lang.String, java.lang.String) */ @@ -917,6 +921,8 @@ * @param nm property name. * @param val default value. * @return the {@code Long} value of the property. + * @throws SecurityException for the same reasons as + * {@link System#getProperty(String) System.getProperty} * @see System#getProperty(java.lang.String) * @see System#getProperty(java.lang.String, java.lang.String) */ From joe.darcy at oracle.com Wed Sep 21 00:03:50 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 20 Sep 2011 17:03:50 -0700 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> Message-ID: <4E7929E6.9070507@oracle.com> Hi Mike. Approved, with a comment. For cases like Boolean, Double, and Long, I'd prefer to see the instance hashCode method rewritten in terms of the new static hashCode method. Cheers, -Joe On 9/20/2011 1:11 PM, Mike Duigou wrote: > Hello all; > > Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). > > http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ > > The webrev combines two issues: > > 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes > 7088952: Add "BYTES" constant to primitive wrapper classes > > Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. > > Thanks, > > Mike From mike.duigou at oracle.com Wed Sep 21 00:41:11 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 Sep 2011 17:41:11 -0700 Subject: JDK 8 code review request for 6268216 "Boolean.getBoolean() throws SecurityException" In-Reply-To: <4E7925C4.9060509@oracle.com> References: <4E7925C4.9060509@oracle.com> Message-ID: <4509CE9A-3CA4-47E1-AC39-57CD876B878E@oracle.com> Looks good. Do you think it's worth eliminating the private static method toBoolean(String) in favour of the public static parseBoolean(String) method? Mike On Sep 20 2011, at 16:46 , Joe Darcy wrote: > Hello. > > Please review this simple fix to add some informative text detailing when an unchecked security exception can be thrown: > > 6268216 "Boolean.getBoolean() throws SecurityException" > http://cr.openjdk.java.net/~darcy/6268216.0/ > > Diff below. > > Thanks, > > -Joe > > --- old/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:18.000000000 -0700 > +++ new/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:17.000000000 -0700 > @@ -229,6 +229,8 @@ > * > * @param name the system property name. > * @return the {@code boolean} value of the system property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see java.lang.System#getProperty(java.lang.String) > * @see java.lang.System#getProperty(java.lang.String, java.lang.String) > */ > @@ -236,8 +238,7 @@ > boolean result = false; > try { > result = toBoolean(System.getProperty(name)); > - } catch (IllegalArgumentException e) { > - } catch (NullPointerException e) { > + } catch (IllegalArgumentException | NullPointerException e) { > } > return result; > } > --- old/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 > +++ new/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 > @@ -797,6 +797,8 @@ > * > * @param nm property name. > * @return the {@code Integer} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see java.lang.System#getProperty(java.lang.String) > * @see java.lang.System#getProperty(java.lang.String, java.lang.String) > */ > @@ -841,6 +843,8 @@ > * @param nm property name. > * @param val default value. > * @return the {@code Integer} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see java.lang.System#getProperty(java.lang.String) > * @see java.lang.System#getProperty(java.lang.String, java.lang.String) > */ > @@ -881,6 +885,8 @@ > * @param nm property name. > * @param val default value. > * @return the {@code Integer} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see System#getProperty(java.lang.String) > * @see System#getProperty(java.lang.String, java.lang.String) > */ > --- old/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 > +++ new/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 > @@ -827,6 +827,8 @@ > * > * @param nm property name. > * @return the {@code Long} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see java.lang.System#getProperty(java.lang.String) > * @see java.lang.System#getProperty(java.lang.String, java.lang.String) > */ > @@ -870,6 +872,8 @@ > * @param nm property name. > * @param val default value. > * @return the {@code Long} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see java.lang.System#getProperty(java.lang.String) > * @see java.lang.System#getProperty(java.lang.String, java.lang.String) > */ > @@ -917,6 +921,8 @@ > * @param nm property name. > * @param val default value. > * @return the {@code Long} value of the property. > + * @throws SecurityException for the same reasons as > + * {@link System#getProperty(String) System.getProperty} > * @see System#getProperty(java.lang.String) > * @see System#getProperty(java.lang.String, java.lang.String) > */ > From joe.darcy at oracle.com Wed Sep 21 00:54:58 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 20 Sep 2011 17:54:58 -0700 Subject: JDK 8 code review request for 6268216 "Boolean.getBoolean() throws SecurityException" In-Reply-To: <4509CE9A-3CA4-47E1-AC39-57CD876B878E@oracle.com> References: <4E7925C4.9060509@oracle.com> <4509CE9A-3CA4-47E1-AC39-57CD876B878E@oracle.com> Message-ID: <4E7935E2.40303@oracle.com> Mike Duigou wrote: > Looks good. > > Do you think it's worth eliminating the private static method toBoolean(String) in favour of the public static parseBoolean(String) method? > Sure; so updated in the revised webrev: http://cr.openjdk.java.net/~darcy/6268216.1/ I'll push after a successful sanity build+test cycle. Thanks, -Joe > Mike > > > > On Sep 20 2011, at 16:46 , Joe Darcy wrote: > > >> Hello. >> >> Please review this simple fix to add some informative text detailing when an unchecked security exception can be thrown: >> >> 6268216 "Boolean.getBoolean() throws SecurityException" >> http://cr.openjdk.java.net/~darcy/6268216.0/ >> >> Diff below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:18.000000000 -0700 >> +++ new/src/share/classes/java/lang/Boolean.java 2011-09-20 16:43:17.000000000 -0700 >> @@ -229,6 +229,8 @@ >> * >> * @param name the system property name. >> * @return the {@code boolean} value of the system property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see java.lang.System#getProperty(java.lang.String) >> * @see java.lang.System#getProperty(java.lang.String, java.lang.String) >> */ >> @@ -236,8 +238,7 @@ >> boolean result = false; >> try { >> result = toBoolean(System.getProperty(name)); >> - } catch (IllegalArgumentException e) { >> - } catch (NullPointerException e) { >> + } catch (IllegalArgumentException | NullPointerException e) { >> } >> return result; >> } >> --- old/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 >> +++ new/src/share/classes/java/lang/Integer.java 2011-09-20 16:43:18.000000000 -0700 >> @@ -797,6 +797,8 @@ >> * >> * @param nm property name. >> * @return the {@code Integer} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see java.lang.System#getProperty(java.lang.String) >> * @see java.lang.System#getProperty(java.lang.String, java.lang.String) >> */ >> @@ -841,6 +843,8 @@ >> * @param nm property name. >> * @param val default value. >> * @return the {@code Integer} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see java.lang.System#getProperty(java.lang.String) >> * @see java.lang.System#getProperty(java.lang.String, java.lang.String) >> */ >> @@ -881,6 +885,8 @@ >> * @param nm property name. >> * @param val default value. >> * @return the {@code Integer} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see System#getProperty(java.lang.String) >> * @see System#getProperty(java.lang.String, java.lang.String) >> */ >> --- old/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 >> +++ new/src/share/classes/java/lang/Long.java 2011-09-20 16:43:19.000000000 -0700 >> @@ -827,6 +827,8 @@ >> * >> * @param nm property name. >> * @return the {@code Long} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see java.lang.System#getProperty(java.lang.String) >> * @see java.lang.System#getProperty(java.lang.String, java.lang.String) >> */ >> @@ -870,6 +872,8 @@ >> * @param nm property name. >> * @param val default value. >> * @return the {@code Long} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see java.lang.System#getProperty(java.lang.String) >> * @see java.lang.System#getProperty(java.lang.String, java.lang.String) >> */ >> @@ -917,6 +921,8 @@ >> * @param nm property name. >> * @param val default value. >> * @return the {@code Long} value of the property. >> + * @throws SecurityException for the same reasons as >> + * {@link System#getProperty(String) System.getProperty} >> * @see System#getProperty(java.lang.String) >> * @see System#getProperty(java.lang.String, java.lang.String) >> */ >> >> > > From david.holmes at oracle.com Wed Sep 21 01:02:21 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Sep 2011 11:02:21 +1000 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> Message-ID: <4E79379D.3070107@oracle.com> Hi Mike, A minor style nit. In Byte you have: + public static final int BYTES = Byte.SIZE / Byte.SIZE; whereas all the other classes use SIZE / Byte.size David On 21/09/2011 6:11 AM, Mike Duigou wrote: > Hello all; > > Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). > > http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ > > The webrev combines two issues: > > 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes > 7088952: Add "BYTES" constant to primitive wrapper classes > > Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. > > Thanks, > > Mike From joe.darcy at oracle.com Wed Sep 21 01:33:56 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 21 Sep 2011 01:33:56 +0000 Subject: hg: jdk8/tl/jdk: 6268216: Boolean.getBoolean() throws SecurityException Message-ID: <20110921013413.B812B4783E@hg.openjdk.java.net> Changeset: 9b2fc8a11421 Author: darcy Date: 2011-09-20 18:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b2fc8a11421 6268216: Boolean.getBoolean() throws SecurityException Reviewed-by: mduigou ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java From mike.duigou at oracle.com Wed Sep 21 01:35:21 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 Sep 2011 18:35:21 -0700 Subject: JDK 8 code review request for 6268216 "Boolean.getBoolean() throws SecurityException" In-Reply-To: <4E7935E2.40303@oracle.com> References: <4E7925C4.9060509@oracle.com> <4509CE9A-3CA4-47E1-AC39-57CD876B878E@oracle.com> <4E7935E2.40303@oracle.com> Message-ID: <124FCF26-9007-4C5A-8B3D-E7B9B888F780@oracle.com> Changes look good. On Sep 20 2011, at 17:54 , Joe Darcy wrote: > Mike Duigou wrote: >> Looks good. >> >> Do you think it's worth eliminating the private static method toBoolean(String) in favour of the public static parseBoolean(String) method? >> > > Sure; so updated in the revised webrev: > > http://cr.openjdk.java.net/~darcy/6268216.1/ From david.holmes at oracle.com Wed Sep 21 02:14:54 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Sep 2011 12:14:54 +1000 Subject: Request for review: 7012206 In-Reply-To: <4E76D19A.4080008@oracle.com> References: <4E76D19A.4080008@oracle.com> Message-ID: <4E79489E.1090101@oracle.com> There was an omission in the original webrev regarding the jtreg invocation changes for PrologSizeSanityCheck.java. The @run directive needs the name of the class to invoke + * @run main/othervm -XX:+UsePerfData PrologSizeSanityCheck Updated webrev at: http://cr.openjdk.java.net/~dholmes/7012206/webrev.01/ I'll proceed with the push as this was a minor omission. David On 19/09/2011 3:22 PM, David Holmes wrote: > This a change to a bunch of serviceability tests (shell scripts that > launch the various j* tools (jps, jstatd, jstack etc)) that I'd like to > push through the TL JDK repo. > > The changes were done by Carlos Lucasius but I'm acting as his "sponsor" > for getting these pushed. > > webrev: http://cr.openjdk.java.net/~dholmes/7012206/webrev/ > > Summary: for correct operation the tools and/or the VM they target must > be running with UsePerfData enabled. This VM option is enabled in Java > SE by default, but is disabled in Java SE Embedded by default. To allow > the tests to be used regardless of the UsePerfdata setting they are > augmented to explicitly turn it on. > > There has been some prior internal debate around how "best" to deal with > this issue and the resulting changes, while somewhat repetitive, are the > simplest approach to take. > > There is one test - jps/jps-Vvml_2.sh - that can not pass with such a > fix because it is actually trying to test the jps output when no > arguments (VM or application) are passed to the target VM. So for that > test I've just added a comment. > > Thanks, > David > From daniel.daugherty at oracle.com Wed Sep 21 02:17:04 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 21 Sep 2011 02:17:04 +0000 Subject: hg: jdk8/tl/jdk: 7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link Message-ID: <20110921021716.6582A47840@hg.openjdk.java.net> Changeset: 029ba13aa0df Author: dcubed Date: 2011-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/029ba13aa0df 7085944: 3/3 FDS: gdb does not find debug symbols for libjsig link Summary: Add support for importing .debuginfo files from HSX. Reviewed-by: phh ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/java/redist/Makefile ! make/java/redist/sajdi/Makefile From david.holmes at oracle.com Wed Sep 21 02:20:45 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 21 Sep 2011 02:20:45 +0000 Subject: hg: jdk8/tl/jdk: 7012206: ~20 tools tests failing due to -XX:-UsePerfData default in Java SE Embedded Message-ID: <20110921022055.8E67647841@hg.openjdk.java.net> Changeset: d177eecda07e Author: dholmes Date: 2011-09-20 22:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d177eecda07e 7012206: ~20 tools tests failing due to -XX:-UsePerfData default in Java SE Embedded Summary: Explicitly enable UsePerfData for the tools that require it to be enabled Reviewed-by: alanb, ohair ! test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jmap/Basic.sh ! test/sun/tools/jps/jps-Defaults.sh ! test/sun/tools/jps/jps-V_2.sh ! test/sun/tools/jps/jps-Vm_2.sh ! test/sun/tools/jps/jps-Vvm.sh ! test/sun/tools/jps/jps-Vvml.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-l_1.sh ! test/sun/tools/jps/jps-l_2.sh ! test/sun/tools/jps/jps-lm.sh ! test/sun/tools/jps/jps-m.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jps/jps-q.sh ! test/sun/tools/jps/jps-v_1.sh ! test/sun/tools/jps/jps-vm_1.sh ! test/sun/tools/jstack/Basic.sh ! test/sun/tools/jstat/jstatClassOutput1.sh ! test/sun/tools/jstat/jstatClassloadOutput1.sh ! test/sun/tools/jstat/jstatCompilerOutput1.sh ! test/sun/tools/jstat/jstatFileURITest1.sh ! test/sun/tools/jstat/jstatGcCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcCauseOutput1.sh ! test/sun/tools/jstat/jstatGcNewCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcNewOutput1.sh ! test/sun/tools/jstat/jstatGcOldCapacityOutput1.sh ! test/sun/tools/jstat/jstatGcOldOutput1.sh ! test/sun/tools/jstat/jstatGcOutput1.sh ! test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatLineCounts1.sh ! test/sun/tools/jstat/jstatLineCounts2.sh ! test/sun/tools/jstat/jstatLineCounts3.sh ! test/sun/tools/jstat/jstatLineCounts4.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstat/jstatPrintCompilationOutput1.sh ! test/sun/tools/jstat/jstatSnap1.sh ! test/sun/tools/jstat/jstatSnap2.sh ! test/sun/tools/jstat/jstatTimeStamp1.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh From aleksey.shipilev at gmail.com Wed Sep 21 09:12:44 2011 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 21 Sep 2011 13:12:44 +0400 Subject: DelayQueue is not Serializable? In-Reply-To: <4E78DCA5.3000008@cs.oswego.edu> References: <4E78DCA5.3000008@cs.oswego.edu> Message-ID: On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea
wrote: > On 09/20/11 12:29, Aleksey Shipilev wrote: >> I've been stumbled upon this for a bit. >> Is there any specific reason DelayQueue is not serializable? Or is it >> an API bug? The backing PriorityQueue *is* serializable. > It was a deliberate decision. > DelayQueues use relative times, so the delays don't make sense > when deserialized at an arbitrary time. And there's no way to > guarantee a correct clock resync to re-normalize. Yes, I understand the concern. However, I don't think it should be enforced by contract. I would argue that is a developer job to tolerate these scenarios. I had met the example when you store Delayed elements with delays in hours, but really try to serialize-deserialize DelayQueue to migrate the data from one server instance to the other, which takes seconds to do. In this scenario, non-serializable DelayQueue is more of hassle. > Plus, no one has ever complained about this, so we > haven't ever revisited it. Can we revisit it some day in the future? From the code perspective, it appears to be point change. Is it the scope for JEP? -Aleksey. From aleksey.shipilev at gmail.com Wed Sep 21 09:17:16 2011 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 21 Sep 2011 13:17:16 +0400 Subject: DelayQueue is not Serializable? In-Reply-To: References: <4E78DCA5.3000008@cs.oswego.edu> Message-ID: On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev wrote: > On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea
wrote: > From the code perspective, it appears to be point change. I take that assertion back. I understand the Delayed elements which are using constant delays need to be carefully recalibrated after deserialization, which will probably require storing advanced metainfo (i.e. "absolute time-to-fire") in serialized form. Most of the examples for DelayQueue I saw had the elements which are self-calibrating, i.e. calling System.cTM() to infer real time. -Aleksey. From Ulf.Zibis at gmx.de Wed Sep 21 10:36:35 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 21 Sep 2011 12:36:35 +0200 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> Message-ID: <4E79BE33.7040107@gmx.de> Hi, why don't we have Boolean.SIZE and Boolean.BYTES ? -Ulf Am 20.09.2011 22:11, schrieb Mike Duigou: > Hello all; > > Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). > > http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ > > The webrev combines two issues: > > 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes > 7088952: Add "BYTES" constant to primitive wrapper classes > > Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. > > Thanks, > > Mike From dl at cs.oswego.edu Wed Sep 21 11:00:55 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 21 Sep 2011 07:00:55 -0400 Subject: DelayQueue is not Serializable? In-Reply-To: References: <4E78DCA5.3000008@cs.oswego.edu> Message-ID: <4E79C3E7.2020100@cs.oswego.edu> On 09/21/11 05:17, Aleksey Shipilev wrote: > On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev > wrote: >> On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea
wrote: >> From the code perspective, it appears to be point change. > > I take that assertion back. I understand the Delayed elements which > are using constant delays need to be carefully recalibrated after > deserialization, which will probably require storing advanced metainfo > (i.e. "absolute time-to-fire") in serialized form. Yes, this is what I was getting at. We try to avoid in j.u.c any invisible conversions between relative and absolute time, because they are filled with potential surprises; including inconsistent clocks across machines, ntp adjustments, resets of system clocks, and the difference in precision between nanoTime and currentTimeMillis. And further, because the "Delayed" elements in the queue are opaque to us, we cannot automate any such conversions or adjustments anyway. If we had an AbsoluteDelayQueue, it would be a good candidate for being serializable. But as it stands, anyone needing to transport delayed tasks across machines can do so by iterating over the queue, and dealing one-by-one with their own Delayed elements wrt the above issues. -Doug From aleksey.shipilev at gmail.com Wed Sep 21 11:06:31 2011 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 21 Sep 2011 15:06:31 +0400 Subject: DelayQueue is not Serializable? In-Reply-To: <4E79C3E7.2020100@cs.oswego.edu> References: <4E78DCA5.3000008@cs.oswego.edu> <4E79C3E7.2020100@cs.oswego.edu> Message-ID: On Wed, Sep 21, 2011 at 3:00 PM, Doug Lea
wrote: > On 09/21/11 05:17, Aleksey Shipilev wrote: >> >> On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev >> ?wrote: >>> >>> On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea
?wrote: >>> ?From the code perspective, it appears to be point change. >> >> I take that assertion back. I understand the Delayed elements which >> are using constant delays need to be carefully recalibrated after >> deserialization, which will probably require storing advanced metainfo >> (i.e. "absolute time-to-fire") in serialized form. > > Yes, this is what I was getting at. We try to avoid in j.u.c > any invisible conversions between relative and absolute time, > because they are filled with potential surprises; including > inconsistent clocks across machines, ntp adjustments, > resets of system clocks, and the difference in precision > between nanoTime and currentTimeMillis. And further, because > the "Delayed" elements in the queue are opaque to us, we cannot > automate any such conversions or adjustments anyway. > > If we had an AbsoluteDelayQueue, it would be a good candidate > for being serializable. > > But as it stands, anyone needing to transport delayed tasks across > machines can do so by iterating over the queue, and dealing > one-by-one with their own Delayed elements wrt the above issues. That's one good explanation, thanks Doug! -Aleksey. From michael.x.mcmahon at oracle.com Wed Sep 21 13:56:42 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 21 Sep 2011 13:56:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20110921135712.F2C4C47861@hg.openjdk.java.net> Changeset: 61a8c602cace Author: michaelm Date: 2011-09-21 14:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61a8c602cace 7079012: test/java/net/NetworkInterface/NetParamsTest.java fails with SocketException getting mac address Reviewed-by: chegar, alanb ! src/solaris/native/java/net/NetworkInterface.c ! test/ProblemList.txt Changeset: e7c2bf7d9d33 Author: michaelm Date: 2011-09-21 14:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7c2bf7d9d33 Merge From mike.duigou at oracle.com Wed Sep 21 23:54:20 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 21 Sep 2011 16:54:20 -0700 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <4E79BE33.7040107@gmx.de> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> Message-ID: <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> I will create a request to add Boolean.SIZE though I am not sure adding a Boolean.BYTES is appropriate for something less than Byte.Size in size. Is it 1-bit? Is it 1-byte? The answer is dependant upon usage and I don't think we can force a single answer. Mike On Sep 21 2011, at 03:36 , Ulf Zibis wrote: > Hi, > > why don't we have Boolean.SIZE and Boolean.BYTES ? > > -Ulf > > > Am 20.09.2011 22:11, schrieb Mike Duigou: >> Hello all; >> >> Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). >> >> http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ >> >> The webrev combines two issues: >> >> 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes >> 7088952: Add "BYTES" constant to primitive wrapper classes >> >> Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. >> >> Thanks, >> >> Mike From david.holmes at oracle.com Thu Sep 22 01:25:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Sep 2011 11:25:18 +1000 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> Message-ID: <4E7A8E7E.9040803@oracle.com> Mike, On 22/09/2011 9:54 AM, Mike Duigou wrote: > I will create a request to add Boolean.SIZE though I am not sure adding a Boolean.BYTES is appropriate for something less than Byte.Size in size. Is it 1-bit? Is it 1-byte? The answer is dependant upon usage and I don't think we can force a single answer. I don't think SIZE or BYTES make any sense for Boolean as booleans are unsized in the Java language. At the VM level they map to ints. For that matter I'm not sure the addition of BYTES is worth the effort. David > Mike > > On Sep 21 2011, at 03:36 , Ulf Zibis wrote: > >> Hi, >> >> why don't we have Boolean.SIZE and Boolean.BYTES ? >> >> -Ulf >> >> >> Am 20.09.2011 22:11, schrieb Mike Duigou: >>> Hello all; >>> >>> Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). >>> >>> http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ >>> >>> The webrev combines two issues: >>> >>> 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes >>> 7088952: Add "BYTES" constant to primitive wrapper classes >>> >>> Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. >>> >>> Thanks, >>> >>> Mike > From weijun.wang at oracle.com Thu Sep 22 04:06:08 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 22 Sep 2011 04:06:08 +0000 Subject: hg: jdk8/tl/jdk: 7092627: use agentvm mode instead of samevm in regtests Message-ID: <20110922040626.49F8A4789D@hg.openjdk.java.net> Changeset: daf87c7be6a1 Author: weijun Date: 2011-09-22 12:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/daf87c7be6a1 7092627: use agentvm mode instead of samevm in regtests Reviewed-by: alanb, dsamersoff ! test/Makefile ! test/com/sun/jdi/sde/MangleStepTest.java ! test/java/util/logging/ParentLoggersTest.java From jonathan.gibbons at oracle.com Thu Sep 22 04:57:32 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 22 Sep 2011 04:57:32 +0000 Subject: hg: jdk8/tl/langtools: 7092965: javac should not close processorClassLoader before end of compilation Message-ID: <20110922045736.D5E79478A0@hg.openjdk.java.net> Changeset: b0d5f00e69f7 Author: jjg Date: 2011-09-21 21:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0d5f00e69f7 7092965: javac should not close processorClassLoader before end of compilation Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/processing/loader/testClose/TestClose.java + test/tools/javac/processing/loader/testClose/TestClose2.java From joe.darcy at oracle.com Thu Sep 22 06:22:30 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 22 Sep 2011 06:22:30 +0000 Subject: hg: jdk8/tl/jdk: 7092404: Add Math.nextDown and Double.isFinite Message-ID: <20110922062248.CB872478A7@hg.openjdk.java.net> Changeset: 6b6b6ee2afd9 Author: darcy Date: 2011-09-21 23:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b6b6ee2afd9 7092404: Add Math.nextDown and Double.isFinite Reviewed-by: mduigou ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/sun/misc/FpUtils.java ! test/java/lang/Double/ParseHexFloatingPoint.java ! test/java/lang/Math/CeilAndFloorTests.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Rint.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java ! test/java/util/Formatter/BasicBigInteger.java ! test/java/util/Formatter/BasicBoolean.java ! test/java/util/Formatter/BasicBooleanObject.java ! test/java/util/Formatter/BasicByte.java ! test/java/util/Formatter/BasicByteObject.java ! test/java/util/Formatter/BasicChar.java ! test/java/util/Formatter/BasicCharObject.java ! test/java/util/Formatter/BasicDateTime.java ! test/java/util/Formatter/BasicDouble.java ! test/java/util/Formatter/BasicDoubleObject.java ! test/java/util/Formatter/BasicFloat.java ! test/java/util/Formatter/BasicFloatObject.java ! test/java/util/Formatter/BasicInt.java ! test/java/util/Formatter/BasicIntObject.java ! test/java/util/Formatter/BasicLong.java ! test/java/util/Formatter/BasicLongObject.java ! test/java/util/Formatter/BasicShort.java ! test/java/util/Formatter/BasicShortObject.java From lvjing at linux.vnet.ibm.com Thu Sep 22 08:40:14 2011 From: lvjing at linux.vnet.ibm.com (Jing Lv) Date: Thu, 22 Sep 2011 16:40:14 +0800 Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails In-Reply-To: <4E411D52.1080509@oracle.com> References: <4E411D52.1080509@oracle.com> Message-ID: <4E7AF46E.5060805@linux.vnet.ibm.com> Hi Alan, I see the status of 7015589 has changed to "fix delivered", so is this fix in the repository(java8?) already? On 2011/8/9 19:43, Alan Bateman wrote: > > A few months back there was a bug report [1] pointing out that it's > possible to continue writing to a BufferedWriter after invoking its > close method and the close fails. A similar issue arises with > BufferedOutputStream and other classes. At issue is whether a stream > (or more generally a resource) is considered closed in the event that > the close method fails. This isn't something that Closeable is clear > on. Joe tells me that this didn't come up in the Coin discussions on > try-with-resources either. > > I think it's safe to say that it would be desirable that close > releases the resources for failing cases as otherwise the resources > may never be released (esp. with try-with-resources usages). > Furthermore, when there are multiple resources involved, or cases like > the bug report where one stream wraps another, then it would be > desirable to keep the state of the resources in sync. To that end, the > changes here propose adding an advisory note to AutoCloseable to > advise implementers to release the underlying resources and to mark > the resource as closed prior to throwing the exception. > > For the specific buffering classes discussed at the time, these are > changed to follow this advise (but their javadoc isn't changed as > there may be other implementations or these classes extended in many > ways). In the case of BufferedWriter it is also fixed so that any > exception from flushing the underlying writer isn't supplanted by the > exception from close. In the case of FilterOutputStream > (BufferedOutputStream extends it) then it is fixed so that it doesn't > ignore the exception thrown when flushing the underlying stream. This > is clearly the right thing to do but it does mean that close can now > throw an IOException for a case where it didn't before. For now I > don't propose to include a compatibility switch but this may be > something that has to revisited later. There are other classes in > java.io that could also be cleaned up but I don't propose to do a > complete audit at this time. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/7015589/webrev/ > > Thanks, > Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html From chris.hegarty at oracle.com Thu Sep 22 08:57:40 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 Sep 2011 09:57:40 +0100 Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails In-Reply-To: <4E7AF46E.5060805@linux.vnet.ibm.com> References: <4E411D52.1080509@oracle.com> <4E7AF46E.5060805@linux.vnet.ibm.com> Message-ID: <4E7AF884.4060208@oracle.com> I see that CR 7015589 was integrated into JDK8 b04. -Chris. On 09/22/11 09:40 AM, Jing Lv wrote: > Hi Alan, > > I see the status of 7015589 has changed to "fix delivered", so is this > fix in the repository(java8?) already? > > On 2011/8/9 19:43, Alan Bateman wrote: >> >> A few months back there was a bug report [1] pointing out that it's >> possible to continue writing to a BufferedWriter after invoking its >> close method and the close fails. A similar issue arises with >> BufferedOutputStream and other classes. At issue is whether a stream >> (or more generally a resource) is considered closed in the event that >> the close method fails. This isn't something that Closeable is clear >> on. Joe tells me that this didn't come up in the Coin discussions on >> try-with-resources either. >> >> I think it's safe to say that it would be desirable that close >> releases the resources for failing cases as otherwise the resources >> may never be released (esp. with try-with-resources usages). >> Furthermore, when there are multiple resources involved, or cases like >> the bug report where one stream wraps another, then it would be >> desirable to keep the state of the resources in sync. To that end, the >> changes here propose adding an advisory note to AutoCloseable to >> advise implementers to release the underlying resources and to mark >> the resource as closed prior to throwing the exception. >> >> For the specific buffering classes discussed at the time, these are >> changed to follow this advise (but their javadoc isn't changed as >> there may be other implementations or these classes extended in many >> ways). In the case of BufferedWriter it is also fixed so that any >> exception from flushing the underlying writer isn't supplanted by the >> exception from close. In the case of FilterOutputStream >> (BufferedOutputStream extends it) then it is fixed so that it doesn't >> ignore the exception thrown when flushing the underlying stream. This >> is clearly the right thing to do but it does mean that close can now >> throw an IOException for a case where it didn't before. For now I >> don't propose to include a compatibility switch but this may be >> something that has to revisited later. There are other classes in >> java.io that could also be cleaned up but I don't propose to do a >> complete audit at this time. >> >> The webrev with the changes is here: >> http://cr.openjdk.java.net/~alanb/7015589/webrev/ >> >> Thanks, >> Alan. >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005732.html >> > From Alan.Bateman at oracle.com Thu Sep 22 08:47:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Sep 2011 09:47:39 +0100 Subject: 7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails In-Reply-To: <4E7AF46E.5060805@linux.vnet.ibm.com> References: <4E411D52.1080509@oracle.com> <4E7AF46E.5060805@linux.vnet.ibm.com> Message-ID: <4E7AF62B.5040106@oracle.com> Jing Lv wrote: > Hi Alan, > > I see the status of 7015589 has changed to "fix delivered", so > is this fix in the repository(java8?) already? Yes, it's been in the jdk8 for several weeks: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf From Ulf.Zibis at gmx.de Thu Sep 22 09:40:05 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Sep 2011 11:40:05 +0200 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> Message-ID: <4E7B0275.3000602@gmx.de> Am 22.09.2011 01:54, schrieb Mike Duigou: > I will create a request to add Boolean.SIZE though I am not sure adding a Boolean.BYTES is appropriate for something less than Byte.Size in size. Is it 1-bit? Is it 1-byte? The answer is dependant upon usage and I don't think we can force a single answer. > > Mike > > On Sep 21 2011, at 03:36 , Ulf Zibis wrote: > >> Hi, >> >> why don't we have Boolean.SIZE and Boolean.BYTES ? >> >> -Ulf Yep, not easy to make a right decision here. One if the questions might be, if SIZE/BYTES are meant as resolution (2**SIZE = number of distinct values) or as memory usage. I would say: SIZE should be meant as resolution, but BYTES as memory usage. This would add additional value to the new introduced constant. So: Boolean.SIZE = 1 Boolean.BYTES = 4 (8 for 64-bit build) > ... At the VM level they map to ints. This is not always true. Arrays of byte are mapped to byte[] in VM. For boolean, it's theoretically possible to map a boolean[32] to one int. > > For that matter I'm not sure the addition of BYTES is worth the effort. Yes or not, I'm unsure. My first feeling was, there _must_ be some additional APIs to justify the change to a new release, here 8. ;-) But I think, it's reasonable to have a short cut when calculating the footprint of some data, instead repeating SIZE/Bytes.SIZE in code. That said, there should be a clear definition, if BYTES is meant as VM-memory-footprint or persistent-storage-footprint e.g. by serialization, or we should have three: MEM_BYTES ARRAY_MEM_BYTES SERIALIZATION_BYTES -Ulf From david.holmes at oracle.com Thu Sep 22 10:04:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Sep 2011 20:04:23 +1000 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <4E7B0275.3000602@gmx.de> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> <4E7B0275.3000602@gmx.de> Message-ID: <4E7B0827.9040007@oracle.com> On 22/09/2011 7:40 PM, Ulf Zibis wrote: > Yep, not easy to make a right decision here. > > One if the questions might be, if SIZE/BYTES are meant as resolution > (2**SIZE = number of distinct values) or as memory usage. > I would say: SIZE should be meant as resolution, but BYTES as memory > usage. This would add additional value to the new introduced constant. > So: > Boolean.SIZE = 1 > Boolean.BYTES = 4 (8 for 64-bit build) I can support the SIZE == resolution position. But BYTES can't mean "memory usage" as that is totally VM dependent and also has platform dependencies, and is not a constant as such due to the way different fields can be packed together. The constants are Java language constants, not VM related, so I think that both SIZE and BYTES have to be resolution. Which still means to me that for boolean BYTES is ambiguous enough to be worth leaving out. >> ... At the VM level they map to ints. > This is not always true. Arrays of byte are mapped to byte[] in VM. For > boolean, it's theoretically possible to map a boolean[32] to one int. According to the VM spec booleans map to ints (Ref 3.11.1). But the VM's native representation could use bit-fields for booleans. >> For that matter I'm not sure the addition of BYTES is worth the effort. > Yes or not, I'm unsure. My first feeling was, there _must_ be some > additional APIs to justify the change to a new release, here 8. ;-) I'm tempted to make a tongue-in-cheek comment about adding lambdas, but I'll resist the temptation ;-) > But I think, it's reasonable to have a short cut when calculating the > footprint of some data, instead repeating SIZE/Bytes.SIZE in code. But given that you can't calculate "footprint" this way the point seems somewhat moot. Cheers, David hat > said, there should be a clear definition, if BYTES is meant as > VM-memory-footprint or persistent-storage-footprint e.g. by > serialization, or we should have three: > MEM_BYTES > ARRAY_MEM_BYTES > SERIALIZATION_BYTES > -Ulf > > From Ulf.Zibis at gmx.de Thu Sep 22 13:23:23 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Sep 2011 15:23:23 +0200 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <4E7B0827.9040007@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> <4E7B0275.3000602@gmx.de> <4E7B0827.9040007@oracle.com> Message-ID: <4E7B36CB.3000702@gmx.de> Am 22.09.2011 12:04, schrieb David Holmes: > On 22/09/2011 7:40 PM, Ulf Zibis wrote: >> Yep, not easy to make a right decision here. >> >> One if the questions might be, if SIZE/BYTES are meant as resolution >> (2**SIZE = number of distinct values) or as memory usage. >> I would say: SIZE should be meant as resolution, but BYTES as memory >> usage. This would add additional value to the new introduced constant. >> So: >> Boolean.SIZE = 1 >> Boolean.BYTES = 4 (8 for 64-bit build) > > I can support the SIZE == resolution position. > > But BYTES can't mean "memory usage" as that is totally VM dependent and also has platform > dependencies, and is not a constant as such due to the way different fields can be packed together. See quote from the original bug report : "The most frequent use of the SIZE constant is to determine the storage space requiresments of the type by Primitive.SIZE / Byte.SIZE" So I would say, this bug is invalid. The only reasonable use case/meaning seems to be to calculate footprint for serialization, which is AFAIK Java language dependent. Then Boolean.BYTES would become unambiguous too. But then the constants would better be defined java.io.DataOutput. I'm additionally wondering, that a bug with state < accepted comes to process. -Ulf From Ulf.Zibis at gmx.de Thu Sep 22 14:10:21 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Sep 2011 16:10:21 +0200 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> Message-ID: <4E7B41CD.9040707@gmx.de> The bug id links in your webrev do not work for me: 7088913 7088952 -Ulf Am 20.09.2011 22:11, schrieb Mike Duigou: > Hello all; > > Here's a webrev for two small additions to the primitive wrapper types (Boolean, Byte, Character, Double, Float, Integer, Long, Short). > > http://cr.openjdk.java.net/~mduigou/7088913/0/webrev/ > > The webrev combines two issues: > > 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes > 7088952: Add "BYTES" constant to primitive wrapper classes > > Stuart Marks has already peer reviewed this for me but a sharp eyed reader may catch something previously missed. As it's already been reviewed I will commit on Friday if there is no feedback. > > Thanks, > > Mike From jonathan.gibbons at oracle.com Thu Sep 22 16:27:09 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 22 Sep 2011 16:27:09 +0000 Subject: hg: jdk8/tl/langtools: 7075721: javac should have public enum for exit codes Message-ID: <20110922162712.23BC3478CE@hg.openjdk.java.net> Changeset: 497571d34112 Author: jjg Date: 2011-09-22 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/497571d34112 7075721: javac should have public enum for exit codes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java ! test/tools/javac/lib/CompileFail.java ! test/tools/javac/util/context/T7021650.java From chris.hegarty at oracle.com Thu Sep 22 16:54:23 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 22 Sep 2011 17:54:23 +0100 Subject: Code Review 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Message-ID: <4E7B683F.5050406@oracle.com> This change is coming from Doug Lea's CVS and I've already review it. It seems that in the re-work that was done for Java 7 we dropped this corner case. STPE.delayedExecute will add the task to the work queue and invoke prestartCoreThread. But prestartCoreThread checks for the worker count (0) being less than corePoolSize (0) and as that is not the case nothing happens. So we have a task in the queue but no thread waiting to execute it. For STPE when the queue is not empty there must always be at least one thread waiting on the queue. http://cr.openjdk.java.net/~chegar/7091003/webrev.00/webrev/ -Chris. From Ulf.Zibis at gmx.de Thu Sep 22 17:18:31 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Sep 2011 19:18:31 +0200 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E73FD52.4020706@oracle.com> References: <4E73FD52.4020706@oracle.com> Message-ID: <4E7B6DE7.8050704@gmx.de> I'm wondering why you don't have moved concerning documentation from sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the scalb operations: /* * The scalb operation should be reasonable ... */ To save some source code footprint and allow better overview, I suggest to erase all javadoc of the moved methods except the deprecated note. -Ulf Am 17.09.2011 03:52, schrieb joe.darcy at oracle.com: > Hello. > > Please review the changes to address > > 7091682 "Move sun.misc.FpUtils code into java.lang.Math" > http://cr.openjdk.java.net/~darcy/7091682.0/ > > As implied by the synopsis, where appropriate JDK-implementation code used to provide > functionality in java.lang.Math and java.lang.StrictMath is moved out of sun.misc.* and into > java.lang.Math. Uses of methods available in java.lang.Math and switched to that entry point as > opposed to the sun.misc one. Additionally, the sun.misc methods whose implementation was moved > were also deprecated. > > Later in JDK 8, I will probably add some of the remaining un-deprecated methods in > sun.misc.FpUtils as java.lang.Math/StrictMath methods. > > Thanks, > > -Joe > From Ulf.Zibis at gmx.de Thu Sep 22 21:07:09 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 22 Sep 2011 23:07:09 +0200 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E7B6DE7.8050704@gmx.de> References: <4E73FD52.4020706@oracle.com> <4E7B6DE7.8050704@gmx.de> Message-ID: <4E7BA37D.1060502@gmx.de> Am 22.09.2011 19:18, schrieb Ulf Zibis: > I'm wondering why you don't have moved concerning documentation from sun.misc.* to > java.lang.(Strict)Math. E.G.: The comment on the scalb operations: > /* > * The scalb operation should be reasonable ... > */ > > To save some source code footprint and allow better overview, I suggest to erase all javadoc of > the moved methods except the deprecated note. BTW: Is it valid use annotation with argument like: @Deprecated("Use Math.scalb.") instead redundant javadoc tag? -Ulf From david.holmes at oracle.com Thu Sep 22 21:34:21 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Sep 2011 07:34:21 +1000 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <4E7B36CB.3000702@gmx.de> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> <4E7B0275.3000602@gmx.de> <4E7B0827.9040007@oracle.com> <4E7B36CB.3000702@gmx.de> Message-ID: <4E7BA9DD.802@oracle.com> On 22/09/2011 11:23 PM, Ulf Zibis wrote: > Am 22.09.2011 12:04, schrieb David Holmes: >> On 22/09/2011 7:40 PM, Ulf Zibis wrote: >>> Yep, not easy to make a right decision here. >>> >>> One if the questions might be, if SIZE/BYTES are meant as resolution >>> (2**SIZE = number of distinct values) or as memory usage. >>> I would say: SIZE should be meant as resolution, but BYTES as memory >>> usage. This would add additional value to the new introduced constant. >>> So: >>> Boolean.SIZE = 1 >>> Boolean.BYTES = 4 (8 for 64-bit build) >> >> I can support the SIZE == resolution position. >> >> But BYTES can't mean "memory usage" as that is totally VM dependent >> and also has platform dependencies, and is not a constant as such due >> to the way different fields can be packed together. > See quote from the original bug report > : > "The most frequent use of the SIZE constant is to determine the storage > space requiresments of the type by Primitive.SIZE / Byte.SIZE" > > So I would say, this bug is invalid. I'm inclined to agree at the moment. Mike: exactly what kind of "storage space requirements" were you considering? David ------ > The only reasonable use case/meaning seems to be to calculate footprint > for serialization, which is AFAIK Java language dependent. Then > Boolean.BYTES would become unambiguous too. But then the constants would > better be defined java.io.DataOutput. > > I'm additionally wondering, that a bug with state < accepted comes to > process. > > -Ulf From david.holmes at oracle.com Thu Sep 22 21:45:42 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Sep 2011 07:45:42 +1000 Subject: Code Review 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero In-Reply-To: <4E7B683F.5050406@oracle.com> References: <4E7B683F.5050406@oracle.com> Message-ID: <4E7BAC86.5060108@oracle.com> Sorry Doug/Chris I should have seen this previously, the order here is wrong: 1552 void ensurePrestart() { 1553 int wc = workerCountOf(ctl.get()); 1554 if (wc == 0) 1555 addWorker(null, false); 1556 else if (wc < corePoolSize) 1557 addWorker(null, true); 1558 } this will always mark the first worker as non-core even if the corePoolSize is > 0. It needs to be swapped void ensurePrestart() { int wc = workerCountOf(ctl.get()); if (wc < corePoolSize) addWorker(null, true); else if (wc == 0) // corePoolSize must be 0 addWorker(null, false); } David ----- On 23/09/2011 2:54 AM, Chris Hegarty wrote: > This change is coming from Doug Lea's CVS and I've already review it. > > It seems that in the re-work that was done for Java 7 we dropped this > corner case. > > STPE.delayedExecute will add the task to the work queue and invoke > prestartCoreThread. But prestartCoreThread checks for the worker count > (0) being less than corePoolSize (0) and as that is not the case nothing > happens. So we have a task in the queue but no thread waiting to execute > it. > > For STPE when the queue is not empty there must always be at least one > thread waiting on the queue. > > http://cr.openjdk.java.net/~chegar/7091003/webrev.00/webrev/ > > -Chris. From dl at cs.oswego.edu Thu Sep 22 23:26:43 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 22 Sep 2011 19:26:43 -0400 Subject: Code Review 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero In-Reply-To: <4E7BAC86.5060108@oracle.com> References: <4E7B683F.5050406@oracle.com> <4E7BAC86.5060108@oracle.com> Message-ID: <4E7BC433.5040100@cs.oswego.edu> On 09/22/11 17:45, David Holmes wrote: > Sorry Doug/Chris I should have seen this previously, the order here is wrong: > > 1552 void ensurePrestart() { > 1553 int wc = workerCountOf(ctl.get()); > 1554 if (wc == 0) > 1555 addWorker(null, false); > 1556 else if (wc < corePoolSize) > 1557 addWorker(null, true); > 1558 } > > this will always mark the first worker as non-core even if the corePoolSize is > > 0. It needs to be swapped Where "needs" means "to be even more accommodating". I agree; done. -Doug From joe.darcy at oracle.com Thu Sep 22 23:29:55 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 22 Sep 2011 16:29:55 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E7BA37D.1060502@gmx.de> References: <4E73FD52.4020706@oracle.com> <4E7B6DE7.8050704@gmx.de> <4E7BA37D.1060502@gmx.de> Message-ID: <4E7BC4F3.7040302@oracle.com> On 9/22/2011 2:07 PM, Ulf Zibis wrote: > Am 22.09.2011 19:18, schrieb Ulf Zibis: >> I'm wondering why you don't have moved concerning documentation from >> sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the scalb >> operations: >> /* >> * The scalb operation should be reasonable ... >> */ >> >> To save some source code footprint and allow better overview, I >> suggest to erase all javadoc of the moved methods except the >> deprecated note. > BTW: Is it valid use annotation with argument like: @Deprecated("Use > Math.scalb.") > instead redundant javadoc tag? > No; the @Deprecated annotation with an informative @deprecated javadoc tag describing what to do instead is the proper style. The @Deprecated annotation type was intentionally defined as marker annotation without a string value. -Joe From david.holmes at oracle.com Fri Sep 23 02:34:06 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Sep 2011 12:34:06 +1000 Subject: Code Review 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero In-Reply-To: <4E7BC433.5040100@cs.oswego.edu> References: <4E7B683F.5050406@oracle.com> <4E7BAC86.5060108@oracle.com> <4E7BC433.5040100@cs.oswego.edu> Message-ID: <4E7BF01E.10001@oracle.com> On 23/09/2011 9:26 AM, Doug Lea wrote: > On 09/22/11 17:45, David Holmes wrote: >> Sorry Doug/Chris I should have seen this previously, the order here is >> wrong: >> >> 1552 void ensurePrestart() { >> 1553 int wc = workerCountOf(ctl.get()); >> 1554 if (wc == 0) >> 1555 addWorker(null, false); >> 1556 else if (wc < corePoolSize) >> 1557 addWorker(null, true); >> 1558 } >> >> this will always mark the first worker as non-core even if the >> corePoolSize is > >> 0. It needs to be swapped > > Where "needs" means "to be even more accommodating". > I agree; done. Sorry Doug I put too much weight on the "core" argument to addWorker. I assumed it was flagging this worker as a core-thread (or not) and so subject to core-thread timeout rules (or not). But it isn't - which of course I should know. ;-) David > -Doug From Ulf.Zibis at gmx.de Fri Sep 23 09:14:38 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 23 Sep 2011 11:14:38 +0200 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E7BC4F3.7040302@oracle.com> References: <4E73FD52.4020706@oracle.com> <4E7B6DE7.8050704@gmx.de> <4E7BA37D.1060502@gmx.de> <4E7BC4F3.7040302@oracle.com> Message-ID: <4E7C4DFE.6060909@gmx.de> Am 23.09.2011 01:29, schrieb Joe Darcy: > On 9/22/2011 2:07 PM, Ulf Zibis wrote: >> Am 22.09.2011 19:18, schrieb Ulf Zibis: >>> I'm wondering why you don't have moved concerning documentation from sun.misc.* to >>> java.lang.(Strict)Math. E.G.: The comment on the scalb operations: >>> /* >>> * The scalb operation should be reasonable ... >>> */ >>> >>> To save some source code footprint and allow better overview, I suggest to erase all javadoc of >>> the moved methods except the deprecated note. >> BTW: Is it valid use annotation with argument like: @Deprecated("Use Math.scalb.") >> instead redundant javadoc tag? >> > > No; the @Deprecated annotation with an informative @deprecated javadoc tag describing what to do > instead is the proper style. > > The @Deprecated annotation type was intentionally defined as marker annotation without a string > value. > OK, thanks Joe. Because I became inclined to file a RFE, is there a source known, where I can read about this intention? 2. What's about moving the sun.misc.* comments? -Ulf From chris.hegarty at oracle.com Fri Sep 23 15:03:02 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 23 Sep 2011 15:03:02 +0000 Subject: hg: jdk8/tl/jdk: 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Message-ID: <20110923150324.316CE4790C@hg.openjdk.java.net> Changeset: 8dab38c07b6b Author: dl Date: 2011-09-23 14:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8dab38c07b6b 7091003: ScheduledExecutorService never executes Runnable with corePoolSize of zero Reviewed-by: dholmes, chegar ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCorePoolSize.java From mike.duigou at oracle.com Fri Sep 23 23:57:27 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 23 Sep 2011 16:57:27 -0700 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <4E7BA9DD.802@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> <4E7B0275.3000602@gmx.de> <4E7B0827.9040007@oracle.com> <4E7B36CB.3000702@gmx.de> <4E7BA9DD.802@oracle.com> Message-ID: <506273E4-BE44-4297-93D7-4F62F3E6C8C8@oracle.com> On Sep 22 2011, at 14:34 , David Holmes wrote: > On 22/09/2011 11:23 PM, Ulf Zibis wrote: >> Am 22.09.2011 12:04, schrieb David Holmes: >>> On 22/09/2011 7:40 PM, Ulf Zibis wrote: >>>> Yep, not easy to make a right decision here. >>>> >>>> One if the questions might be, if SIZE/BYTES are meant as resolution >>>> (2**SIZE = number of distinct values) or as memory usage. >>>> I would say: SIZE should be meant as resolution, but BYTES as memory >>>> usage. This would add additional value to the new introduced constant. >>>> So: >>>> Boolean.SIZE = 1 >>>> Boolean.BYTES = 4 (8 for 64-bit build) >>> >>> I can support the SIZE == resolution position. >>> >>> But BYTES can't mean "memory usage" as that is totally VM dependent >>> and also has platform dependencies, and is not a constant as such due >>> to the way different fields can be packed together. >> See quote from the original bug report >> : >> "The most frequent use of the SIZE constant is to determine the storage >> space requiresments of the type by Primitive.SIZE / Byte.SIZE" >> >> So I would say, this bug is invalid. > > I'm inclined to agree at the moment. > > Mike: exactly what kind of "storage space requirements" were you considering? For cases like DataOutputStream where manifest constants are currently used. The same could apply in NIO byte buffers as well as user code. It's also useful for calculating the size of arrays of primitives (with the exception of boolean). Mike From Ulf.Zibis at gmx.de Sat Sep 24 00:32:47 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 24 Sep 2011 02:32:47 +0200 Subject: Review Request: 7088913/7088952 : Additions to primitive wrappers In-Reply-To: <506273E4-BE44-4297-93D7-4F62F3E6C8C8@oracle.com> References: <53585FD3-C678-4AF5-8E71-BF7B93338959@oracle.com> <4E79BE33.7040107@gmx.de> <3329565C-21F0-45F1-8A86-38E16F79B40F@oracle.com> <4E7B0275.3000602@gmx.de> <4E7B0827.9040007@oracle.com> <4E7B36CB.3000702@gmx.de> <4E7BA9DD.802@oracle.com> <506273E4-BE44-4297-93D7-4F62F3E6C8C8@oracle.com> Message-ID: <4E7D252F.8020207@gmx.de> Am 24.09.2011 01:57, schrieb Mike Duigou: > On Sep 22 2011, at 14:34 , David Holmes wrote: > >> On 22/09/2011 11:23 PM, Ulf Zibis wrote: >>> Am 22.09.2011 12:04, schrieb David Holmes: >>>> On 22/09/2011 7:40 PM, Ulf Zibis wrote: >>>>> Yep, not easy to make a right decision here. >>>>> >>>>> One if the questions might be, if SIZE/BYTES are meant as resolution >>>>> (2**SIZE = number of distinct values) or as memory usage. >>>>> I would say: SIZE should be meant as resolution, but BYTES as memory >>>>> usage. This would add additional value to the new introduced constant. >>>>> So: >>>>> Boolean.SIZE = 1 >>>>> Boolean.BYTES = 4 (8 for 64-bit build) >>>> I can support the SIZE == resolution position. >>>> >>>> But BYTES can't mean "memory usage" as that is totally VM dependent >>>> and also has platform dependencies, and is not a constant as such due >>>> to the way different fields can be packed together. >>> See quote from the original bug report >>> : >>> "The most frequent use of the SIZE constant is to determine the storage >>> space requiresments of the type by Primitive.SIZE / Byte.SIZE" >>> >>> So I would say, this bug is invalid. >> I'm inclined to agree at the moment. >> >> Mike: exactly what kind of "storage space requirements" were you considering? > For cases like DataOutputStream where manifest constants are currently used. The same could apply in NIO byte buffers as well as user code. As I said, I would say, such constant would belong to DataOutput(Stream) and/or NIO package, rather than to the Java type. > It's also useful for calculating the size of arrays of primitives (with the exception of boolean). As David said, this is dependent of the VM implementation. But I would support methods, which retrieve the actual values from the VM. -Ulf From sebastian.sickelmann at gmx.de Sat Sep 24 09:55:40 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 24 Sep 2011 11:55:40 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E7CD5F8.9000501@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> Message-ID: <4E7DA91C.2000600@gmx.de> Am 23.09.2011 20:54, schrieb Sean Mullan: > On 9/17/11 3:09 PM, Sebastian Sickelmann wrote: > >>> i have updated the webrev [0]. >>> But i think that L69 and L72 of the test should be changed to >>> checkMutable and the implementation of the exceptions accordantly. > That's an interesting question. The current implementation in your code is > consistent with java.lang.ClassNotFoundException. I'm curious as to why they > disallowed initCause to be called even if they were created using the > constructors without Throwables. Any idea? Was this discussed in the other lists? I don't know. I can't find anything in the archives (don't know in which time i must search; The commit in ClassNotFoundException is prior rev 0) @core-libs-dev: Does someone remember why this solution was preferred for ClassNotFound? For javax/xml/crypto i would change it to my suggestion (to L69 and L72) above to not break behavior for JSR105. On the other side it would be nice to have a common behavoir on this for all Exceptions in JDK. There are 2 solutions that sound reasonable for me: 1. Preventing initCause when cause is given. And allowing initCause once (if created with an ctor without cause). 2. Preventing initCause in every exception class that has the 4 standard ctors. Only for those Exceptions without the "ctors with cause" the initCause can be called. I like both. No.1 is nearer to the behavoir we actually have and is more flexible than No.2. No.2 is more "secure". You cannot "inject" an cause in ex. after you catches the exception. But you must have the cause to initialize it before you create the exception, this is slightly more inflexible, even if i think this flexibility is not needed anywhere. >>> [0] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3 >>> >>> -- Sebastian >> Any comments / progress on this? > Just a couple of minor comments on the test: > > - the copyright date should only include 2011 > - some minor typos (line number in []): > > [26] s/in/is > [43] s/validating/validate > [98] s/checkImutable/checkImmutable > Updated webrev: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4 > --Sean -- Sebastian From lana.steuck at oracle.com Sun Sep 25 05:53:42 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:42 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20110925055342.904494797F@hg.openjdk.java.net> Changeset: 28cf2aec4dd7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28cf2aec4dd7 Added tag jdk8-b05 for changeset b910aac18c77 ! .hgtags Changeset: 39edfd9d8ff0 Author: lana Date: 2011-09-23 23:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/39edfd9d8ff0 Merge From lana.steuck at oracle.com Sun Sep 25 05:53:44 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:44 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b05 for changeset ff0a3d78e7a2 Message-ID: <20110925055344.90B6A47980@hg.openjdk.java.net> Changeset: d7b8192e7277 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d7b8192e7277 Added tag jdk8-b05 for changeset ff0a3d78e7a2 ! .hgtags From lana.steuck at oracle.com Sun Sep 25 05:53:42 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:42 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b05 for changeset cc1b599b986a Message-ID: <20110925055346.2377D47981@hg.openjdk.java.net> Changeset: 45c43dde7ba7 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/45c43dde7ba7 Added tag jdk8-b05 for changeset cc1b599b986a ! .hgtags From lana.steuck at oracle.com Sun Sep 25 05:53:48 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:48 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b05 for changeset 7d5d91fddbce Message-ID: <20110925055348.7578347982@hg.openjdk.java.net> Changeset: acffff22a946 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/acffff22a946 Added tag jdk8-b05 for changeset 7d5d91fddbce ! .hgtags From lana.steuck at oracle.com Sun Sep 25 05:53:42 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:42 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b05 for changeset dce7d24674f4 Message-ID: <20110925055354.A6DC047983@hg.openjdk.java.net> Changeset: 0db80d8e77fc Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0db80d8e77fc Added tag jdk8-b05 for changeset dce7d24674f4 ! .hgtags From lana.steuck at oracle.com Sun Sep 25 05:53:59 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:53:59 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20110925055408.5E3CB47984@hg.openjdk.java.net> Changeset: 4e754e4b0a52 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4e754e4b0a52 Added tag jdk8-b05 for changeset 5304c2a17d4b ! .hgtags Changeset: d2422276f9da Author: lana Date: 2011-09-19 19:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2422276f9da Merge Changeset: 0c6f79fc8441 Author: lana Date: 2011-09-23 23:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0c6f79fc8441 Merge From lana.steuck at oracle.com Sun Sep 25 05:55:40 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sun, 25 Sep 2011 05:55:40 +0000 Subject: hg: jdk8/tl/jdk: 16 new changesets Message-ID: <20110925055827.D672E47985@hg.openjdk.java.net> Changeset: 266f095ce636 Author: mbykov Date: 2011-09-09 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/266f095ce636 7087932: Wrong legal notice introduced in the JDK8 changeset c43af666d130 Reviewed-by: ohair, darcy ! src/share/classes/java/lang/VirtualMachineError.java Changeset: 0b32369b83d8 Author: schien Date: 2011-09-14 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b32369b83d8 Merge Changeset: 907bcdbc2593 Author: schien Date: 2011-09-15 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/907bcdbc2593 Added tag jdk8-b05 for changeset 0b32369b83d8 ! .hgtags Changeset: fbfd97a14af1 Author: dbuck Date: 2011-09-02 04:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbfd97a14af1 7074386: fallback to fontconfig..bfc/properties if fontconfig... Summary: fallback to fontconfig..bfc/properties if fontconfig... is not found Reviewed-by: prr, robm ! src/share/classes/sun/awt/FontConfiguration.java Changeset: b8b6587b9574 Author: prr Date: 2011-09-06 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8b6587b9574 7050826: Hebrew characters are not rendered on OEL 5.6 Reviewed-by: bae, jgodinez ! src/solaris/native/sun/awt/fontpath.c Changeset: 22149eb5a8c9 Author: lana Date: 2011-09-09 17:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22149eb5a8c9 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: 22c60997bf3c Author: rupashka Date: 2011-08-30 13:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22c60997bf3c 7080281: AbtsractButton.checkVerticalKey()/checkHorizontalKey() methods do not specify returned value Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java Changeset: 970ff8d5bbe7 Author: denis Date: 2011-09-01 17:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/970ff8d5bbe7 7081012: REGRESSION:Component.transferFocusBackward invokes clearGlobalFocusOwner() Reviewed-by: ant ! src/share/classes/java/awt/Component.java Changeset: 25564f7b29c4 Author: denis Date: 2011-09-05 18:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25564f7b29c4 7071248: IME composition window does not disappear when file dialog is closed : Japanese WinXP Reviewed-by: naoto, art ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: 98bb40dbc144 Author: vikram Date: 2011-09-07 03:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98bb40dbc144 7012783: JFileChooser fails to resolve DFS links on Windows Vista SP2 Summary: Changes to code to handle DFS links Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 7fbc8d86c477 Author: rupashka Date: 2011-09-09 17:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fbc8d86c477 7024118: possible hardcoded mnemonic for JFileChooser metal and motif l&f Reviewed-by: alexp Contributed-by: Charles Lee ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Changeset: 8c7cecbc3567 Author: lana Date: 2011-09-09 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c7cecbc3567 Merge - make/com/oracle/net/Makefile - src/share/classes/sun/io/ByteToCharASCII.java - src/share/classes/sun/io/ByteToCharBig5.java - src/share/classes/sun/io/ByteToCharBig5_HKSCS.java - src/share/classes/sun/io/ByteToCharBig5_Solaris.java - src/share/classes/sun/io/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.java - src/share/classes/sun/io/CharToByteBig5.java - src/share/classes/sun/io/CharToByteBig5_HKSCS.java - src/share/classes/sun/io/CharToByteBig5_Solaris.java - src/share/classes/sun/io/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - test/sun/nio/cs/TestISCII91.java Changeset: 0595eb21e9b5 Author: lana Date: 2011-09-12 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0595eb21e9b5 Merge Changeset: d8658f371633 Author: lana Date: 2011-09-12 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8658f371633 Merge ! src/share/classes/java/awt/Component.java Changeset: bdb870cc269e Author: lana Date: 2011-09-19 19:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdb870cc269e Merge Changeset: 651a7afae763 Author: lana Date: 2011-09-23 23:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/651a7afae763 Merge From weijun.wang at oracle.com Mon Sep 26 09:14:09 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 26 Sep 2011 09:14:09 +0000 Subject: hg: jdk8/tl/jdk: 7094842: test/javax/security/auth/Subject/{Synch.java, Synch2.java, Synch3.java} loop forever in agentvm mode Message-ID: <20110926091418.ADD72479BF@hg.openjdk.java.net> Changeset: 2116952e4459 Author: weijun Date: 2011-09-26 17:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2116952e4459 7094842: test/javax/security/auth/Subject/{Synch.java,Synch2.java,Synch3.java} loop forever in agentvm mode Reviewed-by: alanb ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java From chris.hegarty at oracle.com Mon Sep 26 14:05:59 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 26 Sep 2011 14:05:59 +0000 Subject: hg: jdk8/tl/jdk: 7094141: test/sun/misc/JarIndex/metaInfFilenames/Basic.java no longer compiles Message-ID: <20110926140622.4F2F0479CB@hg.openjdk.java.net> Changeset: 8876d1dec4d7 Author: chegar Date: 2011-09-26 15:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8876d1dec4d7 7094141: test/sun/misc/JarIndex/metaInfFilenames/Basic.java no longer compiles Reviewed-by: alanb ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java From joe.darcy at oracle.com Tue Sep 27 03:11:50 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 26 Sep 2011 20:11:50 -0700 Subject: JDK 8 code review request for 7091682 "Move sun.misc.FpUtils code into java.lang.Math" In-Reply-To: <4E7C4DFE.6060909@gmx.de> References: <4E73FD52.4020706@oracle.com> <4E7B6DE7.8050704@gmx.de> <4E7BA37D.1060502@gmx.de> <4E7BC4F3.7040302@oracle.com> <4E7C4DFE.6060909@gmx.de> Message-ID: <4E813EF6.80800@oracle.com> Hi Ulf. On 9/23/2011 2:14 AM, Ulf Zibis wrote: > Am 23.09.2011 01:29, schrieb Joe Darcy: >> On 9/22/2011 2:07 PM, Ulf Zibis wrote: >>> Am 22.09.2011 19:18, schrieb Ulf Zibis: >>>> I'm wondering why you don't have moved concerning documentation >>>> from sun.misc.* to java.lang.(Strict)Math. E.G.: The comment on the >>>> scalb operations: >>>> /* >>>> * The scalb operation should be reasonable ... >>>> */ >>>> >>>> To save some source code footprint and allow better overview, I >>>> suggest to erase all javadoc of the moved methods except the >>>> deprecated note. >>> BTW: Is it valid use annotation with argument like: @Deprecated("Use >>> Math.scalb.") >>> instead redundant javadoc tag? >>> >> >> No; the @Deprecated annotation with an informative @deprecated >> javadoc tag describing what to do instead is the proper style. >> >> The @Deprecated annotation type was intentionally defined as marker >> annotation without a string value. >> > OK, thanks Joe. > > Because I became inclined to file a RFE, is there a source known, > where I can read about this intention? This RFE was filed and subsequently closed some time ago; the rationale is discussed in the bug evaluation: 5105736 "(anno) Deprecated annotation needs way to add comment and/or replacement api (value)" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5105736 > > 2. What's about moving the sun.misc.* comments? > > Next time I'm going something else which touches sun.misc.FpUtils, I might adjust the comments; I don't see that as important enough to do on its own since the comments should only be seen by people browsing the sources directly. Cheers, -Joe From mark.reinhold at oracle.com Tue Sep 27 04:56:51 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 26 Sep 2011 21:56:51 -0700 Subject: JEP 102: Process API updates Message-ID: <20110927045651.DDEA3F29@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/102 - Mark From mark.reinhold at ORACLE.COM Tue Sep 27 04:58:15 2011 From: mark.reinhold at ORACLE.COM (mark.reinhold at ORACLE.COM) Date: Mon, 26 Sep 2011 21:58:15 -0700 Subject: JEP 103: Parallel Array Sorting Message-ID: <20110927045815.599BDF29@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/103 - Mark From chris.hegarty at oracle.com Tue Sep 27 09:41:39 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 27 Sep 2011 09:41:39 +0000 Subject: hg: jdk8/tl/jdk: 7084030: DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected Message-ID: <20110927094200.4920C47A06@hg.openjdk.java.net> Changeset: 7f1aca641910 Author: chegar Date: 2011-09-26 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f1aca641910 7084030: DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected Summary: Use family of connected IP address to retrieve desired local address of the datagram socket Reviewed-by: chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c + test/java/net/DatagramSocket/ChangingAddress.java From sean.mullan at oracle.com Tue Sep 27 15:38:14 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 27 Sep 2011 11:38:14 -0400 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E7DA91C.2000600@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> Message-ID: <4E81EDE6.9050205@oracle.com> On 9/24/11 5:55 AM, Sebastian Sickelmann wrote: > Am 23.09.2011 20:54, schrieb Sean Mullan: >> On 9/17/11 3:09 PM, Sebastian Sickelmann wrote: >> >>>> i have updated the webrev [0]. >>>> But i think that L69 and L72 of the test should be changed to >>>> checkMutable and the implementation of the exceptions accordantly. >> That's an interesting question. The current implementation in your code is >> consistent with java.lang.ClassNotFoundException. I'm curious as to why they >> disallowed initCause to be called even if they were created using the >> constructors without Throwables. Any idea? Was this discussed in the other lists? > I don't know. I can't find anything in the archives (don't know in which > time i must search; The commit in ClassNotFoundException is prior rev 0) > > @core-libs-dev: Does someone remember why this solution was preferred > for ClassNotFound? See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385429 I think I know the reason. If you allow initCause to be called when a cause is not initially provided, then getCause will still return null, which seems wrong. > For javax/xml/crypto i would change it to my suggestion (to L69 and L72) > above to not break behavior for JSR105. On the other side it would be > nice to have a common behavoir on this for all Exceptions in JDK. > > There are 2 solutions that sound reasonable for me: > 1. Preventing initCause when cause is given. And allowing initCause once > (if created with an ctor without cause). > 2. Preventing initCause in every exception class that has the 4 standard > ctors. Only for those Exceptions without the "ctors with cause" the > initCause can be called. > > I like both. > No.1 is nearer to the behavoir we actually have and is more flexible > than No.2. > No.2 is more "secure". You cannot "inject" an cause in ex. after you > catches the exception. But you must have the cause to initialize it > before you create the exception, this is slightly more inflexible, even > if i think this flexibility is not needed anywhere. > > >>>> [0] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3 >>>> >>>> -- Sebastian >>> Any comments / progress on this? >> Just a couple of minor comments on the test: >> >> - the copyright date should only include 2011 >> - some minor typos (line number in []): >> >> [26] s/in/is >> [43] s/validating/validate >> [98] s/checkImutable/checkImmutable >> > Updated webrev: > > http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4 BTW, the popup ads on this site are very annoying. Can you move your webrev to a different site? --Sean From sean.mullan at oracle.com Tue Sep 27 19:50:04 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 27 Sep 2011 19:50:04 +0000 Subject: hg: jdk8/tl/jdk: 7088502: Security libraries don't build with javac -Werror Message-ID: <20110927195022.E8CEE47A21@hg.openjdk.java.net> Changeset: 62e1389fdb0a Author: mullan Date: 2011-09-26 17:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62e1389fdb0a 7088502: Security libraries don't build with javac -Werror Summary: Changes to files in src/share/classes/com/sun/org/apache/xml/internal/security and its subpackages to remove warnings Reviewed-by: mullan Contributed-by: kurchi.subhra.hazra at oracle.com ! make/com/sun/org/apache/xml/Makefile ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java From sebastian.sickelmann at gmx.de Wed Sep 28 04:36:07 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 28 Sep 2011 06:36:07 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E81EDE6.9050205@oracle.com> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> Message-ID: <4E82A437.30907@gmx.de> Am 27.09.2011 17:38, schrieb Sean Mullan: > On 9/24/11 5:55 AM, Sebastian Sickelmann wrote: >> Am 23.09.2011 20:54, schrieb Sean Mullan: >>> On 9/17/11 3:09 PM, Sebastian Sickelmann wrote: >>> >>>>> i have updated the webrev [0]. >>>>> But i think that L69 and L72 of the test should be changed to >>>>> checkMutable and the implementation of the exceptions accordantly. >>> That's an interesting question. The current implementation in your code is >>> consistent with java.lang.ClassNotFoundException. I'm curious as to why they >>> disallowed initCause to be called even if they were created using the >>> constructors without Throwables. Any idea? Was this discussed in the other lists? >> I don't know. I can't find anything in the archives (don't know in which >> time i must search; The commit in ClassNotFoundException is prior rev 0) >> >> @core-libs-dev: Does someone remember why this solution was preferred >> for ClassNotFound? > See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385429 > > I think I know the reason. If you allow initCause to be called when a cause is > not initially provided, then getCause will still return null, which seems wrong. > getCause() of Throwable and all classes that doesn't had a chaining before Throwable introduces it, doing this excact this way. Whats wrong on this? return (cause==this ? null : cause); // Where the initial value(uninitialied) of cause is this. >> For javax/xml/crypto i would change it to my suggestion (to L69 and L72) >> above to not break behavior for JSR105. On the other side it would be >> nice to have a common behavoir on this for all Exceptions in JDK. >> >> There are 2 solutions that sound reasonable for me: >> 1. Preventing initCause when cause is given. And allowing initCause once >> (if created with an ctor without cause). >> 2. Preventing initCause in every exception class that has the 4 standard >> ctors. Only for those Exceptions without the "ctors with cause" the >> initCause can be called. I think all exceptions that had no chaining before Throwable introduces it actually follow solution 1, where some of the Exceptions don't have a ctor with a cause. All those who had chaining before (ex. ClassNotFoundException) actually follow solution 2. But whats the correct solution? >> I like both. >> No.1 is nearer to the behavoir we actually have and is more flexible >> than No.2. >> No.2 is more "secure". You cannot "inject" an cause in ex. after you >> catches the exception. But you must have the cause to initialize it >> before you create the exception, this is slightly more inflexible, even >> if i think this flexibility is not needed anywhere. >> If i think longer about it, i like No.2 a bit more. It is nearer what i would expect how a exception should react on giving a cause. >>>>> [0] http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3 >>>>> >>>>> -- Sebastian >>>> Any comments / progress on this? >>> Just a couple of minor comments on the test: >>> >>> - the copyright date should only include 2011 >>> - some minor typos (line number in []): >>> >>> [26] s/in/is >>> [43] s/validating/validate >>> [98] s/checkImutable/checkImmutable >>> >> Updated webrev: >> >> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4 > BTW, the popup ads on this site are very annoying. Can you move your webrev to a > different site? > Working on that. Sorry for the annoying ads. > --Sean -- Sebastian From weijun.wang at oracle.com Wed Sep 28 06:21:47 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 28 Sep 2011 06:21:47 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20110928062227.E7E7B47A39@hg.openjdk.java.net> Changeset: 79582fcc8329 Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79582fcc8329 7089889: Krb5LoginModule.login() throws an exception if used without a keytab Reviewed-by: xuelei, valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java + test/sun/security/krb5/auto/NoInitNoKeytab.java Changeset: 9b951304bd0a Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b951304bd0a 7077640: gss wrap for cfx doesn't handle rrc != 0 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/RRC.java Changeset: 8d88e694441c Author: weijun Date: 2011-09-28 14:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d88e694441c 7077646: gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java + test/sun/security/krb5/auto/AcceptorSubKey.java From xueming.shen at oracle.com Wed Sep 28 19:18:34 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Sep 2011 12:18:34 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset Message-ID: <4E83730A.8060106@oracle.com> Hi, [I combined the proposed charge for #7082884, in which no one appears to be interested:-) into this one] Unicode Standard added "Addition Constraints on conversion of ill-formed UTF-8" in version 5.1 [1] and updated in 6.0 again with further "clarification" [2] regarding how a "conformance" implementation should handle ill-formed UTF-8 byte sequence. Basically it says (1) the conversion process should not interpret any ill-formed code unit sequence (2) such process must not treat any adjacent well-formed code unit sequences as being part of those ill-formed code unit sequences (3) and recommend a "best practice" of "maximal valid sub-part" for replacement The new UTF-8 charset implementation we put in JDK7 (and back-ported to previous release since then) follows the new constraints in most cases, except (1) The decoder still accepts "historical" 3 bytes surrogates and 6 bytes surrogate pair (the encoder never outputs such sequence). Unicode Standard "tightened" its UTF-8 definition in ver 3.2 [3], as "Most notable among the corrigenda to the Standard is a further tightening of the definition of UTF-8, to eliminate irregular UTF-8 and to bring the Unicode specification of UTF-8 more completely into line with other specifications of UTF-8." So the 3-byte/6-byte surrogates are now defined as "ill-formed" code unit sequence, instead of "irregular" [5] in ver 3.1 (2) While no longer accepting the "historical" 5-byte, 6-byte UTF-8 byte sequence, the decoder treats these 5/6-byte sequence as ONE malformed unit. As a result these bytes get replaced by one replacement character, when "replace for malformed" is desirable (as in new String(bytes), for example). According the latest Unicode standard [2], however, because the leading byte of these 5/6-byte sequence is no longer an illegal appearance of the UTF-8, these bytes should be treated as 5-6 individual ill-formed bytes. (3)Corner case like ill-formed byte sequence ED 31 is not handled correctly/ consistently, as described in #7082884 [6] The reason behind (1) and (2) is mostly the compatibility concern. As suggested in TR#26 [4] (in which it defines CESU-8, a separate UTF encoding scheme that uses 3-6-byte sequence for supplementary characters, instead of 4-byte sequence in UTF-8), there are apps/data over there that do use surrogates pair in "UTF-8" form. To change the UTF-8 charset to follow standard obviously will break someone's code when they migrate/upgrade from JDK/JRE N to N+1, something we try really hard to avoid. That said, given almost decade has passed and we are now at Unicode 6, I think the possibility of breaking someone's code/date of upgrading UTF-8 to do the "right thing" is small/minor. So I proposed here (1) to upgrade the JDK8 UTF-8 implementation to strictly follow the standard to a) reject 3-byte surrogate/6-byte surrogate pair b) treats 5/6-byte surrogate as individual ill-formed bytes. c) fix the corner case bug #7082884 (2) to add CESU-8 charset into JDK/JRE's charset repository (for those still prefer/work on 3-6 bytes surrogate, in "UTF-8" form) Here is the webrev. The change will need to go through some "in-compatible change" review process, but I think we can start the code review/discussion here first. http://cr.openjdk.java.net/~sherman/7096080/webrev/ -Sherman [1] http://www.unicode.org/versions/Unicode5.1.0/#Notable_Changes [2] http://www.unicode.org/versions/Unicode6.0.0/#Conformance_Changes [3] http://www.unicode.org/reports/tr28/tr28-3.html [4] http://unicode.org/reports/tr26/ [5] http://unicode.org/versions/corrigendum1.html [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007722.html From Ulf.Zibis at gmx.de Wed Sep 28 22:14:11 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 29 Sep 2011 00:14:11 +0200 Subject: Codereview request for 7082884: Incorrect UTF8 conversion for sequence ED 31 In-Reply-To: <4E77A44D.8050706@oracle.com> References: <4E77A44D.8050706@oracle.com> Message-ID: <4E839C33.10806@gmx.de> Am 19.09.2011 22:21, schrieb Xueming Shen: > > The current implementation decode > > new String(new byte[]{(byte)0xed, 31}, "UTF8") Bug 7082884 refers to ED 31, so it should be: new String(new byte[]{(byte)0xed, 0x31}, "UTF8") -Ulf From Ulf.Zibis at gmx.de Wed Sep 28 22:44:32 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 29 Sep 2011 00:44:32 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E83730A.8060106@oracle.com> References: <4E83730A.8060106@oracle.com> Message-ID: <4E83A350.5010102@gmx.de> Hi Sherman, 1. bug 7096080 is not visible at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096080 2. bug 7096080 seems to be a duplicate of 6798514 - Charset UTF-8 accepts CESU-8 codings which was closed. It should be reopened again. 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results 4. Consider additionally 6184334 - Massive duplication of code in contains(Charset) methods in UTF-* Charsets 5. IMHO charset CESU-8 should be hosted in extended-charsets, otherwise it should be added to java.nio.StandardCharsets -Ulf From xueming.shen at oracle.com Thu Sep 29 03:27:13 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Sep 2011 20:27:13 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E83A350.5010102@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> Message-ID: <4E83E591.2090103@oracle.com> Hi, On 9/28/2011 3:44 PM, Ulf Zibis wrote: > Hi Sherman, > > 1. bug 7096080 is not visible at > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7096080 It might take couple days for it to show up on bugs.sun.com. But it has exactly the same content as my previous email. In fact I simply copy/pasted them into email. > 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results > > (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) It appears the Unicode Standard now explicitly recommends to return the malformed length 2, what UTF-8 is doing now, for this scenario (2) new byte[]{(byte)0xE1, (byte)0x40 ---> CoderResult.malformedForLength(1) The change proposed actually fixed this one already (malformed length 1 (3) new byte[]{(byte)0xC0} ---> CoderResult.malformedForLength(1) Technically this is not a bug, the decoder will return malformedlength 1 if you go with decode(bf,cf, true). But yes, it would be desirable to return malformed length 1 without waiting for second byte. The code/webrev has been updated to just do this as "expected". Now the 2-byte sequence entry check has been updated to } else if ((b1 >> 5) == -2 && (b1 & 0x1e) != 0) { ... } and I no longer check the first byte for malformed2(), in which I think has the smallest performance impact for 2 bytes sequence. I ran several rounds of benchmark testing, I did not see significant difference. I will try more later. I'm not sure I understand the suggested b1 < -0x3e patch, I don't see we can simply replace ((b1 >> 5) == -2) with (b1 < -0x3e). Anyway, I hope now you are motivated to take a deep look at the code:-) and maybe want to run all your tests to confirm the change is fine. This change does expose an existing bug/issue in StreamDecoder, in which the StreamDecoder fails to replace a "malformed" input, in which a "leading byte" is at the end of the stream. This is why I commended the line in Errors. I will file a bug for this one later. > 5. IMHO charset CESU-8 should be hosted in extended-charsets, > otherwise it should be added to java.nio.StandardCharsets > We have lots of charsets provided via the "standard charset provider" (in rt.jar) but not listed in StandardCharsets. -Sherman From patrick.zhang at oracle.com Thu Sep 29 19:00:39 2011 From: patrick.zhang at oracle.com (patrick.zhang at oracle.com) Date: Thu, 29 Sep 2011 12:00:39 -0700 (PDT) Subject: Auto Reply: core-libs-dev Digest, Vol 53, Issue 40 Message-ID: I will be out of office from Sep 29th to Oct 7th. Any emergency please contact with my manager sandeep.konchady at oracle.com. Or you can get to me through +86 10 13341050230 directly. From omajid at redhat.com Thu Sep 29 20:54:50 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 29 Sep 2011 16:54:50 -0400 Subject: hidden directories under /etc/ Message-ID: <4E84DB1A.2050301@redhat.com> Hi, I recently discovered that openjdk creates hidden directories under /etc/ [1]. I would like to propose that those directories should be made explicit. webrev at: http://cr.openjdk.java.net/~omajid/webrevs/hidden-dirs-under-etc/01/ The patch modifies the directory names to make them visible by default. The directory /etc/java/ already exists on many linux distributions - jpackage uses it - so it seems like a useful replacement directory. The patch also renames systemPrefs to system-prefs to make it slightly more consistent with existing directories under /etc/. Does anyone have any thoughts or concerns? Thanks, Omair [1] https://bugzilla.redhat.com/show_bug.cgi?id=741821 From Alan.Bateman at oracle.com Thu Sep 29 21:43:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Sep 2011 22:43:04 +0100 Subject: hidden directories under /etc/ In-Reply-To: <4E84DB1A.2050301@redhat.com> References: <4E84DB1A.2050301@redhat.com> Message-ID: <4E84E668.1010501@oracle.com> Omair Majid wrote: > Hi, > > I recently discovered that openjdk creates hidden directories under > /etc/ [1]. I would like to propose that those directories should be > made explicit. > > webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/hidden-dirs-under-etc/01/ > > The patch modifies the directory names to make them visible by > default. The directory /etc/java/ already exists on many linux > distributions - jpackage uses it - so it seems like a useful > replacement directory. > > The patch also renames systemPrefs to system-prefs to make it slightly > more consistent with existing directories under /etc/. > > Does anyone have any thoughts or concerns? I don't think the preferences API is used very often but changing the default locations will mean that existing preferences are lost (unless you set java.util.prefs.userRoot and java.util.prefs.systemRoot to their original location). I'm not sure if it's worth the disruption it might cause. -Alan. From omajid at redhat.com Thu Sep 29 21:57:27 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 29 Sep 2011 17:57:27 -0400 Subject: hidden directories under /etc/ In-Reply-To: <4E84E668.1010501@oracle.com> References: <4E84DB1A.2050301@redhat.com> <4E84E668.1010501@oracle.com> Message-ID: <4E84E9C7.4000602@redhat.com> On 09/29/2011 05:43 PM, Alan Bateman wrote: > Omair Majid wrote: >> Hi, >> >> I recently discovered that openjdk creates hidden directories under >> /etc/ [1]. I would like to propose that those directories should be >> made explicit. >> >> webrev at: >> http://cr.openjdk.java.net/~omajid/webrevs/hidden-dirs-under-etc/01/ >> >> The patch modifies the directory names to make them visible by >> default. The directory /etc/java/ already exists on many linux >> distributions - jpackage uses it - so it seems like a useful >> replacement directory. >> >> The patch also renames systemPrefs to system-prefs to make it slightly >> more consistent with existing directories under /etc/. >> >> Does anyone have any thoughts or concerns? > I don't think the preferences API is used very often but changing the > default locations will mean that existing preferences are lost (unless > you set java.util.prefs.userRoot and java.util.prefs.systemRoot to their > original location). I'm not sure if it's worth the disruption it might > cause. > Yes, I am a little afraid of the disruption too, which is why I proposed it for jdk8, not for a 7 update. That said, I think these directories should be visible by default. We are storing preferences in it and hiding the directory from the sysadmin serves no purpose. In fact, programs like rkhunter tend to flag them as suspicious [1]. Thanks, Omair [1] http://www.google.com/search?q=rkhunter+etc+java From xueming.shen at oracle.com Thu Sep 29 22:27:46 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 29 Sep 2011 15:27:46 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E84E025.3010105@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E84E025.3010105@gmx.de> Message-ID: <4E84F0E2.6010503@oracle.com> On 09/29/2011 02:16 PM, Ulf Zibis wrote: > Please use spaces with ternary operators: Lines 155, 216 > > For short you could use sr instead srcRemaining, consistent to sa, sp, sl. > > 420 // returns -1 if there is malformed byte(s) and the > better: > 420 // returns -1 if there is/are malformed byte(s) and the > > 466 sp -=3; > There should be a space: sp -= 3; Webrev has been updated accordingly. > > 280 if (Character.isSurrogate(c)) > 281 return malformedForLength(src, sp, dst, > dp, 3); > Shouldn't we return cr.length() = 1to allow remaining 2 bytes to be > interpreted again ? > Actually I don't know the answer. My reading of D93a/D93b suggests that we might interpret it as a whole, given the bytes are actually in well-formed byte pattern range listed in Table 3.7, but "ill-formed" simply because they are surrogate value not scale value, so I would interpret the whole 3 bytes as a maximal subpart. Given D93a/b is "best practices for Using U+fffd", either way should be fine. We do have Unicode expert on the list, so maybe they can share their opinion on what is the "desired"/recommended behavior in this case, from Standard point view? > > Am 29.09.2011 05:27, schrieb Xueming Shen: >> Hi, >> >> On 9/28/2011 3:44 PM, Ulf Zibis wrote: >>> 5. IMHO charset CESU-8 should be hosted in extended-charsets, >>> otherwise it should be added to java.nio.StandardCharsets >>> >> >> We have lots of charsets provided via the "standard charset provider" >> (in rt.jar) but not listed in StandardCharsets. > Yes, but the reasonable to add CESU-8 to StandardCharsets was the > supposed demand to treat all unicode charsets equivalent. > > Otherwise there is no obstacle to host CESU-8 in extended-charsets. > IMHO, CESU-8 addresses corner case compatibility issues, but not > "standard" requirements. To put CESU-8 into "standard charset provider" (it is only an implementation details) does not mean it is a "standard" requirement, it just means it is bundled into rt.jar. The reason I put it there is to make sure it is together with the UTF-8, with the assumption is that you might need it around when using the updated UTF-8, which no longer handles those 3/6-byte surrogates. -Sherman From mark.reinhold at oracle.com Fri Sep 30 04:41:26 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Sep 2011 21:41:26 -0700 Subject: JEP 108: Collections Enhancements from Third-Party Libraries Message-ID: <20110930044126.2D8559DB@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/108 - Mark From mark.reinhold at oracle.com Fri Sep 30 04:42:02 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Sep 2011 21:42:02 -0700 Subject: JEP 109: Enhance Core Libraries with Lambda Message-ID: <20110930044202.370C49DF@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/109 - Mark From pdoubleya at gmail.com Fri Sep 30 06:13:58 2011 From: pdoubleya at gmail.com (Patrick Wright) Date: Fri, 30 Sep 2011 08:13:58 +0200 Subject: JEP 108: Collections Enhancements from Third-Party Libraries In-Reply-To: <20110930044126.2D8559DB@eggemoggin.niobe.net> References: <20110930044126.2D8559DB@eggemoggin.niobe.net> Message-ID: Mark, in comparison to the other JEPs proposed recently, this seems quite vague. There is a brief list of candidate collections nestled in the very middle of the JEP, but that's it. Given that the "alternative collection libraries" have existed for many years, it seems to me the author has enough material to draw from to pull up a more concrete list. If the JEP does not wish to list all of them, then I think the JEP should describe what what will drive the selection - a survey? A general request for suggestions? Automated analysis of large codebases? A friendly community member, Patrick On Fri, Sep 30, 2011 at 6:41 AM, wrote: > Posted: http://openjdk.java.net/jeps/108 > > - Mark > From Alan.Bateman at oracle.com Fri Sep 30 12:24:54 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Sep 2011 13:24:54 +0100 Subject: hidden directories under /etc/ In-Reply-To: <4E84E9C7.4000602@redhat.com> References: <4E84DB1A.2050301@redhat.com> <4E84E668.1010501@oracle.com> <4E84E9C7.4000602@redhat.com> Message-ID: <4E85B516.1080308@oracle.com> Omair Majid wrote: > > Yes, I am a little afraid of the disruption too, which is why I > proposed it for jdk8, not for a 7 update. > > That said, I think these directories should be visible by default. We > are storing preferences in it and hiding the directory from the > sysadmin serves no purpose. In fact, programs like rkhunter tend to > flag them as suspicious [1]. > I agree that /etc/.java looks suspicious but I'm not sure if it's worth the potential disruption. I guess we could consider supporting two locations. If the new location exists then we use it; if only the old location exists then use that. That would at least ensure that existing system preferences wouldn't get lost when you move to jdk8 and it would mean that over time that system preferences would be stored in the new location. This approach would of course run into problems if there were a mix of jdk versions on a system -- ie: run something with jdk8 on a new system and it stores the preferences in the new location. Run it again with jdk7 or older and it will appear that the preferences have been lost. That said, I believe that the intention with preferences is that the format could evolve over time and so having a older jdk read or update the system preferences that were created by a newer jdk might not be a big concern. I would be more cautious with user preferences as my guess is that they are used more than system preferences (because system preferences need privileges to create). I also think that ~/.java/.systemPrefs isn't a major concern (unlike /etc/.java). -Alan. From Ulf.Zibis at gmx.de Fri Sep 30 14:09:33 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 30 Sep 2011 16:09:33 +0200 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E83E591.2090103@oracle.com> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> Message-ID: <4E85CD9D.1050401@gmx.de> Hi, Am 29.09.2011 05:27, schrieb Xueming Shen: > Hi, > > On 9/28/2011 3:44 PM, Ulf Zibis wrote >> 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results >> >> > > (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> CoderResult.malformedForLength(1) > It appears the Unicode Standard now explicitly recommends to return the malformed length 2, > what UTF-8 is doing now, for this scenario My idea behind is, that in case of malformed length 1 a consecutive call to the decode loop would again return another malformed length 1, to ensure 2 replacement chars in the output string. (Not sure, if that is expected in this corner case.) > I'm not sure I understand the suggested b1 < -0x3e patch, I don't see we can simply replace > ((b1 >> 5) == -2) with (b1 < -0x3e). You must see the b1 < -0x3e in combination with the following b1 < -0x20. ;-) But now I have a better "if...else if" switch. :-) - saves the shift operations - only 1 comparison per case - only 1 constant to load per case - helps compiler to benefit from 1 byte constants and op-codes - much better readable byte b1 = sa[sp]; // help compiler to benefit from 1 byte op-codes and constants // byte b1 = src.get();// help compiler to benefit from 1 byte op-codes and constants Byte1Switch: if (b1 >= 0) { // 1 byte, 7 bits: 0xxxxxxx ...return x; } else if (b1 < (byte)0xe0) { // 2 bytes, 11 bits: 110xxxxx 10xxxxxx if (b1 < (byte)0xc2) // b1 < C2 not legal break Byte1Switch; ...return x; } else if (b1 < (byte)0xf0) { // 3 bytes, 16 bits: 1110xxxx 10xxxxxx 10xxxxxx ...return x; } else if (b1 < (byte)0xf8) { // 4 bytes, 21 bits: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx ...return x; } return malformed(src, sp, dst, dp, 1); // return malformed(src, mark, 1); > > Anyway, I hope now you are motivated to take a deep look at the code:-) and maybe want to > run all your tests to confirm the change is fine. At the moment I don't have a well running system, so my contribution must remain limited. :-( About motivation: For me it's kinda frustrating, seeing a bug from external voluntary contributor as "Will Not Fix", but some time later an Oracle employ?e creates an "equivalent" new bug from scratch without at least referring to the existing ones, e.g.: 6798514, 6795537. Additionally I think, now it's the right time to re-evaluate bug 4508058 - UTF-8 encoding does not recognize initial BOM. Cheers, -Ulf From sebastian.sickelmann at gmx.de Fri Sep 30 18:15:25 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 30 Sep 2011 20:15:25 +0200 Subject: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4E82A437.30907@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> Message-ID: <4E86073D.9050101@gmx.de> Am 28.09.2011 06:36, schrieb Sebastian Sickelmann: > Am 27.09.2011 17:38, schrieb Sean Mullan: >> On 9/24/11 5:55 AM, Sebastian Sickelmann wrote: >>> Am 23.09.2011 20:54, schrieb Sean Mullan: >>>> On 9/17/11 3:09 PM, Sebastian Sickelmann wrote: >>>> >>>>>> i have updated the webrev [0]. >>>>>> But i think that L69 and L72 of the test should be changed to >>>>>> checkMutable and the implementation of the exceptions accordantly. >>>> That's an interesting question. The current implementation in your >>>> code is >>>> consistent with java.lang.ClassNotFoundException. I'm curious as to >>>> why they >>>> disallowed initCause to be called even if they were created using the >>>> constructors without Throwables. Any idea? Was this discussed in >>>> the other lists? >>> I don't know. I can't find anything in the archives (don't know in >>> which >>> time i must search; The commit in ClassNotFoundException is prior >>> rev 0) >>> >>> @core-libs-dev: Does someone remember why this solution was preferred >>> for ClassNotFound? >> See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385429 >> >> I think I know the reason. If you allow initCause to be called when a >> cause is >> not initially provided, then getCause will still return null, which >> seems wrong. >> > getCause() of Throwable and all classes that doesn't had a chaining > before > Throwable introduces it, doing this excact this way. Whats wrong on this? > > return (cause==this ? null : cause); // Where the initial > value(uninitialied) of cause is this. Does this make sense? I actually not sure i understand you right. > > >>> For javax/xml/crypto i would change it to my suggestion (to L69 and >>> L72) >>> above to not break behavior for JSR105. On the other side it would be >>> nice to have a common behavoir on this for all Exceptions in JDK. >>> >>> There are 2 solutions that sound reasonable for me: >>> 1. Preventing initCause when cause is given. And allowing initCause >>> once >>> (if created with an ctor without cause). >>> 2. Preventing initCause in every exception class that has the 4 >>> standard >>> ctors. Only for those Exceptions without the "ctors with cause" the >>> initCause can be called. > I think all exceptions that had no chaining before Throwable > introduces it actually follow > solution 1, where some of the Exceptions don't have a ctor with a cause. > All those who had chaining before (ex. ClassNotFoundException) > actually follow > solution 2. > > But whats the correct solution? >>> I like both. >>> No.1 is nearer to the behavoir we actually have and is more flexible >>> than No.2. >>> No.2 is more "secure". You cannot "inject" an cause in ex. after you >>> catches the exception. But you must have the cause to initialize it >>> before you create the exception, this is slightly more inflexible, even >>> if i think this flexibility is not needed anywhere. >>> > If i think longer about it, i like No.2 a bit more. It is nearer what > i would expect how a exception should react on giving a cause. >>>>>> [0] >>>>>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_3 >>>>>> >>>>>> -- Sebastian >>>>> Any comments / progress on this? >>>> Just a couple of minor comments on the test: >>>> >>>> - the copyright date should only include 2011 >>>> - some minor typos (line number in []): >>>> >>>> [26] s/in/is >>>> [43] s/validating/validate >>>> [98] s/checkImutable/checkImmutable >>>> >>> Updated webrev: >>> >>> http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_4 >> BTW, the popup ads on this site are very annoying. Can you move your >> webrev to a >> different site? Ok. Done this. Sorry for the annoying ads, again. http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html >> > Working on that. Sorry for the annoying ads. >> --Sean > -- Sebastian From kelly.ohair at oracle.com Fri Sep 30 19:43:44 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 30 Sep 2011 12:43:44 -0700 Subject: Test failure on Ubuntu 10.04 java/nio/channels/FileChannel/Transfers.java Message-ID: <57208D7E-BA58-43A3-B604-C0A639A68B2E@oracle.com> Has anyone seen this testcase fail like this? FAILED: java/nio/channels/FileChannel/Transfers.java ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Some tests failed REASON: Assumed action based on file name: run main Transfers TIME: 3.337 seconds messages: command: main Transfers reason: Assumed action based on file name: run main Transfers elapsed time (seconds): 3.337 STDOUT: From file channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 From user channel: 0 1 2 3 4 5 6 7 8 9 15 16 17 31 32 33 63 64 65 127 128 129 255 256 257 511 512 513 1023 1024 1025 2047 2048 2049 4095 4096 4097 8191 8192 8193 16383 16384 16385 32767 To file channel: 0 FAILURE: FileChannel, offset 0, length 1 Transfers$Failure: Wrong position: 0 (expected 1) at Transfers$FileTarget.verify(Transfers.java:316) at Transfers.testTo(Transfers.java:449) at Transfers.main(Transfers.java:527) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:680) at java.lang.Thread.run(Thread.java:722) .... goes on forever ... :^( -kto From mark.reinhold at oracle.com Fri Sep 30 14:32:07 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 30 Sep 2011 07:32:07 -0700 Subject: JEP 108: Collections Enhancements from Third-Party Libraries In-Reply-To: pdoubleya@gmail.com; Fri, 30 Sep 2011 08:13:58 +0200; Message-ID: <20110930143207.C0FBE931@eggemoggin.niobe.net> 2011/9/29 23:13 -0700, pdoubleya at gmail.com: > Mark, > > in comparison to the other JEPs proposed recently, this seems quite > vague. There is a brief list of candidate collections nestled in the > very middle of the JEP, but that's it. Given that the "alternative > collection libraries" have existed for many years, it seems to me the > author has enough material to draw from to pull up a more concrete > list. If the JEP does not wish to list all of them, then I think the > JEP should describe what what will drive the selection - a survey? A > general request for suggestions? Automated analysis of large > codebases? These are all fair points, and I look forward to seeing Mike's replies. Note that this JEP is only in the "Posted" state. The expectation is, as with all JEPs, that it will be refined as the work progresses and in response to feedback such as yours. - Mark From darryl.mocek at oracle.com Fri Sep 30 20:20:17 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 30 Sep 2011 13:20:17 -0700 Subject: JDK 8 Code Review Request for 5029031 (coll) Collections.checkedQueue(Queue, Class) is missing Message-ID: <4E862481.6050800@oracle.com> Hello. Please review this patch to add CheckedQueue to Collections. Test case provided. Webrev at: http://cr.openjdk.java.net/~mduigou/4533691/0/webrev/ Thanks, Darryl From xueming.shen at oracle.com Fri Sep 30 20:46:42 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Sep 2011 13:46:42 -0700 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4E85CD9D.1050401@gmx.de> References: <4E83730A.8060106@oracle.com> <4E83A350.5010102@gmx.de> <4E83E591.2090103@oracle.com> <4E85CD9D.1050401@gmx.de> Message-ID: <4E862AB2.7090605@oracle.com> On 09/30/2011 07:09 AM, Ulf Zibis wrote: >>> >> >> (1) new byte[]{(byte)0xE1, (byte)0x80, (byte)0x42} ---> >> CoderResult.malformedForLength(1) >> It appears the Unicode Standard now explicitly recommends to return >> the malformed length 2, >> what UTF-8 is doing now, for this scenario > My idea behind is, that in case of malformed length 1 a consecutive > call to the decode loop would again return another malformed length 1, > to ensure 2 replacement chars in the output string. (Not sure, if that > is expected in this corner case.) Unicode Standard's "best practices" D93a/b recommends to return 2 in this case. > 3. Consider additionally 6795537 - UTF_8$Decoder returns wrong results > > > >> I'm not sure I understand the suggested b1 < -0x3e patch, I don't >> see we can simply replace >> ((b1 >> 5) == -2) with (b1 < -0x3e). > You must see the b1 < -0x3e in combination with the following b1 < > -0x20. ;-) > > But now I have a better "if...else if" switch. :-) > - saves the shift operations > - only 1 comparison per case > - only 1 constant to load per case > - helps compiler to benefit from 1 byte constants and op-codes > - much better readable I believe we changed from (b1 < xyz) to (b1 >> x) == -2 back to 2009(?) because the benchmark shows the "shift" version is slightly faster. Do you have any number shows any difference now. My non-scientific benchmark still suggests the "shift" type is faster on -server vm, no significant difference on -client vm. ------------------ your new switch--------------- (1) -server Method Millis Ratio Decoding 1b UTF-8 : 125 1.000 Decoding 2b UTF-8 : 2558 20.443 Decoding 3b UTF-8 : 3439 27.481 Decoding 4b UTF-8 : 2030 16.221 (2) -client Decoding 1b UTF-8 : 335 1.000 Decoding 2b UTF-8 : 1041 3.105 Decoding 3b UTF-8 : 2245 6.694 Decoding 4b UTF-8 : 1254 3.741 ------------------ existing "shift"--------------- (1) -server Decoding 1b UTF-8 : 134 1.000 Decoding 2b UTF-8 : 1891 14.106 Decoding 3b UTF-8 : 2934 21.886 Decoding 4b UTF-8 : 2133 15.913 (2) -client Decoding 1b UTF-8 : 341 1.000 Decoding 2b UTF-8 : 949 2.560 Decoding 3b UTF-8 : 2321 6.255 Decoding 4b UTF-8 : 1278 3.446 -sherman