From mike.duigou at oracle.com Sat Jun 1 00:32:07 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 01 Jun 2013 00:32:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130601003239.7507A48EA2@hg.openjdk.java.net> Changeset: fc0b3e86fdcf Author: mduigou Date: 2013-05-31 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0b3e86fdcf 8015686: {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException Reviewed-by: dholmes, alanb, psandoz ! src/share/classes/java/util/IntSummaryStatistics.java ! src/share/classes/java/util/LongSummaryStatistics.java Changeset: 198de8103df2 Author: mduigou Date: 2013-05-31 17:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/198de8103df2 Merge From Alan.Bateman at oracle.com Sat Jun 1 10:05:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Jun 2013 11:05:34 +0100 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51A8E8D7.9030208@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> <51A8E8D7.9030208@oracle.com> Message-ID: <51A9C76E.4090101@oracle.com> On 31/05/2013 19:15, Dan Xu wrote: > > On 05/29/2013 04:54 AM, Alan Bateman wrote: >> Thanks for taking this one. >> >> The changes mean that IAE is now thrown for cases where it wasn't >> thrown previously and I'm wondering if this is worth doing. It might >> be simpler to just throw IOException on the grounds that creating the >> file will fail. >> >> One other thing to consider is that "\" is a valid name of a file on >> some platforms. I suspect you'll need to delegate to the FileSystem >> to check the suffix/prefix. Alternatively in >> TempDirectory.generateFile you could create a File from >> prefix/n/suffix and call getName to check that its matches. If not >> then throw an exception. >> >> -Alan. > Thanks for your good review. I have updated my changes. And it is > uploaded at, http://cr.openjdk.java.net/~dxu/8013827/webrev.01/. This updated changes look good, minor nit in that the missing space in two occurrences of "if(". For the test SpecialTempFile then I wonder if the 2s is sufficient, I could imagine this test failing intermittently when under load. Is a thread pool even needed because with the fix then createFileTemp should either work or throw an IOException (no hang). -Alan From eric.mccorkle at oracle.com Sat Jun 1 12:32:55 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Sat, 01 Jun 2013 08:32:55 -0400 Subject: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh In-Reply-To: <51A7C880.50700@oracle.com> References: <51A7A03D.2080103@oracle.com> <51A7C880.50700@oracle.com> Message-ID: <51A9E9F7.6020303@oracle.com> Thanks, Kumar. Do I have a second? Note: JPRT has been unreliable lately, so it may be a while before I can put this in. On 05/30/13 17:45, Kumar Srinivasan wrote: > Hi Erik, > > This looks good, historically the #!shell was inserted after the > CopyRight, > because it was thought that the automated CR updaters might get confused. > > I am cc'ing Dave K, just so that he is aware of this. > > Thanks > Kumar > >> Hello, >> >> Please review this simple patch which fixes an issue with several of the >> shell script tests, namely that they do not start with #!/bin/sh >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8014834/ >> >> The bug is here: >> http://bugs.sun.com/view_bug.do?bug_id=8014834 >> >> Thanks, >> Eric > From dl at cs.oswego.edu Sat Jun 1 16:59:25 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 01 Jun 2013 12:59:25 -0400 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51A8AF47.3000802@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> Message-ID: <51AA286D.9020306@cs.oswego.edu> On 05/31/13 10:10, Alan Bateman wrote: > Assuming Doug and Mike are okay with this then I suggest we try to get it into > jdk8/tl soon so that it has a few days bake time before Lana grabs the changes > from jdk8/tl for b94. I think Mike is going to sponsor this. > On cross-checking with ConcurrentHashMap, all looks OK except that it should include a fix for a problem introduced once when changing comparison orders and not picked up until recently retesting CHM. (sorry.) Here's a diff against webrev 0.3 *** HashMap.java~ Fri May 31 13:58:38 2013 --- HashMap.java Sat Jun 1 12:52:11 2013 *************** *** 490,499 **** (dir = ((Comparable)k).compareTo(pk)) == 0) { // assert pk != null; TreeNode r, pl, pr; // check both sides ! if ((pr = p.right) != null && h >= pr.entry.hash && (r = getTreeNode(h, k, pr, cc)) != null) return r; ! else if ((pl = p.left) != null && h <= pl.entry.hash) dir = -1; else // nothing there break; --- 490,499 ---- (dir = ((Comparable)k).compareTo(pk)) == 0) { // assert pk != null; TreeNode r, pl, pr; // check both sides ! if ((pr = p.right) != null (r = getTreeNode(h, k, pr, cc)) != null) return r; ! else if ((pl = p.left) != null) dir = -1; else // nothing there break; *************** *** 534,540 **** else if (cc == null || comparableClassFor(pk) != cc || (dir = ((Comparable)k).compareTo(pk)) == 0) { TreeNode r, pr; ! if ((pr = p.right) != null && h >= pr.entry.hash && (r = getTreeNode(h, k, pr, cc)) != null) return r; else // continue left --- 534,540 ---- else if (cc == null || comparableClassFor(pk) != cc || (dir = ((Comparable)k).compareTo(pk)) == 0) { TreeNode r, pr; ! if ((pr = p.right) != null && (r = getTreeNode(h, k, pr, cc)) != null) return r; else // continue left From vicente.romero at oracle.com Sat Jun 1 21:00:17 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 01 Jun 2013 21:00:17 +0000 Subject: hg: jdk8/tl/langtools: 8010737: javac, known parameter's names should be copied to automatically generated constructors for inner classes Message-ID: <20130601210023.612D248EB9@hg.openjdk.java.net> Changeset: e9855150c5b0 Author: vromero Date: 2013-06-01 21:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9855150c5b0 8010737: javac, known parameter's names should be copied to automatically generated constructors for inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java From vicente.romero at oracle.com Sat Jun 1 21:10:17 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 01 Jun 2013 21:10:17 +0000 Subject: hg: jdk8/tl/langtools: 6695379: Copy method annotations and parameter annotations to synthetic bridge methods Message-ID: <20130601211020.6BA4348EBA@hg.openjdk.java.net> Changeset: ec871c3e8337 Author: vromero Date: 2013-06-01 22:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec871c3e8337 6695379: Copy method annotations and parameter annotations to synthetic bridge methods Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/ReflectionVisitor.java ! test/tools/javac/MethodParameters/Tester.java + test/tools/javac/T6695379/AnnotationsAreNotCopiedToBridgeMethodsTest.java From dan.xu at oracle.com Sun Jun 2 02:16:43 2013 From: dan.xu at oracle.com (Dan Xu) Date: Sat, 01 Jun 2013 19:16:43 -0700 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51A9C76E.4090101@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> <51A8E8D7.9030208@oracle.com> <51A9C76E.4090101@oracle.com> Message-ID: <51AAAB0B.1080202@oracle.com> On 06/01/2013 03:05 AM, Alan Bateman wrote: > On 31/05/2013 19:15, Dan Xu wrote: >> >> On 05/29/2013 04:54 AM, Alan Bateman wrote: >>> Thanks for taking this one. >>> >>> The changes mean that IAE is now thrown for cases where it wasn't >>> thrown previously and I'm wondering if this is worth doing. It might >>> be simpler to just throw IOException on the grounds that creating >>> the file will fail. >>> >>> One other thing to consider is that "\" is a valid name of a file on >>> some platforms. I suspect you'll need to delegate to the FileSystem >>> to check the suffix/prefix. Alternatively in >>> TempDirectory.generateFile you could create a File from >>> prefix/n/suffix and call getName to check that its matches. If not >>> then throw an exception. >>> >>> -Alan. >> Thanks for your good review. I have updated my changes. And it is >> uploaded at, http://cr.openjdk.java.net/~dxu/8013827/webrev.01/. > This updated changes look good, minor nit in that the missing space in > two occurrences of "if(". > > For the test SpecialTempFile then I wonder if the 2s is sufficient, I > could imagine this test failing intermittently when under load. Is a > thread pool even needed because with the fix then createFileTemp > should either work or throw an IOException (no hang). > > -Alan Thanks, Alan. I am going to fix the format issue on "if(". As for the SpecialTempFile testcase, I wonder whether these regression tests may happen to be used to test earlier JDK versions. In that case, the thread pool will help the test framework find the test failure easily. Otherwise, I agree it adds extra overhead into this test. -Dan From ali.ebrahimi1781 at gmail.com Sun Jun 2 21:05:26 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 3 Jun 2013 01:35:26 +0430 Subject: Upgrade to JAXP 1.5 Breaks Existing Apps Message-ID: I update to jdk8b92 and almost all apps deals with xml parsing breaks. in other word, current default value for XMLConstants.ACCESS_EXTERNAL_DTD property is empty string. This should be at least change to "file". From mike.duigou at oracle.com Sun Jun 2 22:41:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sun, 02 Jun 2013 22:41:33 +0000 Subject: hg: jdk8/tl/jdk: 8007398: Peformance improvements to Integer and Long string formatting. Message-ID: <20130602224212.0147748EC8@hg.openjdk.java.net> Changeset: c8410ce73ad6 Author: mduigou Date: 2013-02-12 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8410ce73ad6 8007398: Peformance improvements to Integer and Long string formatting. Reviewed-by: mduigou, martin, darcy, briangoetz Contributed-by: Steven Schlansker , Mike Duigou ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java + test/java/lang/IntegralPrimitiveToString.java From brent.christian at oracle.com Mon Jun 3 05:56:32 2013 From: brent.christian at oracle.com (Brent Christian) Date: Sun, 02 Jun 2013 22:56:32 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51AA286D.9020306@cs.oswego.edu> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> <51AA286D.9020306@cs.oswego.edu> Message-ID: <51AC3010.3060609@oracle.com> On 6/1/13 9:59 AM, Doug Lea wrote: > On cross-checking with ConcurrentHashMap, all looks OK except that > it should include a fix for a problem introduced once when changing > comparison orders and not picked up until recently retesting CHM. (sorry.) > Here's a diff against webrev 0.3 Thank you. I take it this change: > TreeNode r, pl, pr; // check both sides > ! if ((pr = p.right) != null > (r = getTreeNode(h, k, pr, cc)) != null) should be if ((pr = p.right) != null && ^^ as with the similar change later in the file. I went ahead and created a new webrev. It includes this change, and the comment changes suggested by Alan: http://cr.openjdk.java.net/~bchristi/8005698/webrev.04/ A .diff with the HashMap.java changes between webrev.03 and .04 are here, in case it's helpful: http://cr.openjdk.java.net/~bchristi/8005698/webrev.04/HashMap.java.diff Thanks again, -Brent From aleksey.shipilev at oracle.com Mon Jun 3 06:43:22 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 03 Jun 2013 10:43:22 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51A8C54A.4020008@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> Message-ID: <51AC3B0A.2000803@oracle.com> On 05/31/2013 07:44 PM, Aleksey Shipilev wrote: > [The fields in the same contention group may not be pair-wise isolated] Added this to the relevant section. Please see the webrev: http://cr.openjdk.java.net/~shade/8014966/webrev.05/ Martin, David, Mike, please take a final look! -Aleksey. From david.holmes at oracle.com Mon Jun 3 06:57:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Jun 2013 16:57:20 +1000 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51AC3B0A.2000803@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> Message-ID: <51AC3E50.8020409@oracle.com> Looks fine to me. Thanks, David On 3/06/2013 4:43 PM, Aleksey Shipilev wrote: > On 05/31/2013 07:44 PM, Aleksey Shipilev wrote: >> [The fields in the same contention group may not be pair-wise isolated] > > Added this to the relevant section. Please see the webrev: > http://cr.openjdk.java.net/~shade/8014966/webrev.05/ > > Martin, David, Mike, please take a final look! > > -Aleksey. > From paul.sandoz at oracle.com Mon Jun 3 07:56:42 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Jun 2013 09:56:42 +0200 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51AC3010.3060609@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> <51AA286D.9020306@cs.oswego.edu> <51AC3010.3060609@oracle.com> Message-ID: Hi Brent, On Jun 3, 2013, at 7:56 AM, Brent Christian wrote: > I went ahead and created a new webrev. It includes this change, and the comment changes suggested by Alan: > > http://cr.openjdk.java.net/~bchristi/8005698/webrev.04/ > A minor thing: take it or leave it :-) In HashMap: 2207 void addEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { 2208 // assert key != null; 2209 if ((size >= threshold) && (null != table[bucketIndex])) { 2210 resize(2 * table.length); 2211 hash = hash(key); 2212 bucketIndex = indexFor(hash, table.length); 2213 } 2214 createEntry(hash, key, value, bucketIndex, checkIfNeedTree); 2215 } You could re-verify the bucket size if the table is resized rather than in createEntry, since that AFAICT is the only case where conditions after the call to addEntry might change. Pau. From paul.sandoz at oracle.com Mon Jun 3 08:44:08 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Jun 2013 08:44:08 +0000 Subject: hg: jdk8/tl/jdk: 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE Message-ID: <20130603084437.9FA2948ED1@hg.openjdk.java.net> Changeset: f3c7c5f753dc Author: psandoz Date: 2013-06-03 10:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c7c5f753dc 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE Reviewed-by: chegar ! src/share/classes/java/util/PrimitiveIterator.java + test/java/util/Iterator/PrimitiveIteratorDefaults.java From paul.sandoz at oracle.com Mon Jun 3 08:53:02 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Jun 2013 08:53:02 +0000 Subject: hg: jdk8/tl/jdk: 8014731: j.u.stream.StreamSupport class has default constructor generated Message-ID: <20130603085315.D311948ED2@hg.openjdk.java.net> Changeset: 44ef47f3efed Author: psandoz Date: 2013-06-03 10:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44ef47f3efed 8014731: j.u.stream.StreamSupport class has default constructor generated Summary: This change set also fixes broken links Reviewed-by: alanb, chegar Contributed-by: Paul Sandoz , Henry Jen ! src/share/classes/java/util/stream/StreamSupport.java From Alan.Bateman at oracle.com Mon Jun 3 10:07:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Jun 2013 11:07:46 +0100 Subject: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh In-Reply-To: <51A9E9F7.6020303@oracle.com> References: <51A7A03D.2080103@oracle.com> <51A7C880.50700@oracle.com> <51A9E9F7.6020303@oracle.com> Message-ID: <51AC6AF2.7060809@oracle.com> On 01/06/2013 13:32, Eric McCorkle wrote: > Thanks, Kumar. Do I have a second? > For the jdk repository then only one reviewer is required although in specialized or complicated areas then having a reviewer that knows the area well is important. In this case I think you are good to go. Just on Kumar's comment then I think a lot of the shell tests start with "#!" already so I would expect that scripts that check or fix-up copyright headers should be able to deal with this already. Another point, and maybe this for follow-on work, is that many of the shell tests don't have anything so it would be good to fix them up too. We should of course keep an eye out for opportunities to replace the shell tests as our ultimate goal should be to get rid of them. -Alan. From paul.sandoz at oracle.com Mon Jun 3 10:15:02 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Jun 2013 12:15:02 +0200 Subject: RFR 8015790 Remove duplicate spliterator tests Message-ID: <5B7CCFDC-10D1-4D68-BBA6-D391B46C4B92@oracle.com> Hi, This RFR proposes to remove some duplicate spliterator tests. The tests: http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java are duplicates of: http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java and the former should be removed. Paul. From Alan.Bateman at oracle.com Mon Jun 3 10:23:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Jun 2013 11:23:20 +0100 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51AAAB0B.1080202@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> <51A8E8D7.9030208@oracle.com> <51A9C76E.4090101@oracle.com> <51AAAB0B.1080202@oracle.com> Message-ID: <51AC6E98.9070907@oracle.com> On 02/06/2013 03:16, Dan Xu wrote: > : > > As for the SpecialTempFile testcase, I wonder whether these regression > tests may happen to be used to test earlier JDK versions. In that > case, the thread pool will help the test framework find the test > failure easily. Otherwise, I agree it adds extra overhead into this test. My concern is mostly the timeout as we've had so many problems with tests failing intermittently when the machine is very busy. In this case, I could imagine this failing when there are tests running concurrently in a pool VMs and at the same time competing with AV software on Windows that is sucking the life out of the system. In general, it's not always possible to write a test that behaves well when run an unpatched-JDK. Deadlocks, crashes, and hangs are just some examples where a test might timeout or jtreg needs to spin up a new VM to continue the test execution. So while important for one-off verification then it's probably not worth spending too much effort trying to get it to behaves well on an JDK that doesn't have the fix. -Alan. From Alan.Bateman at oracle.com Mon Jun 3 10:24:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Jun 2013 11:24:41 +0100 Subject: RFR 8015790 Remove duplicate spliterator tests In-Reply-To: <5B7CCFDC-10D1-4D68-BBA6-D391B46C4B92@oracle.com> References: <5B7CCFDC-10D1-4D68-BBA6-D391B46C4B92@oracle.com> Message-ID: <51AC6EE9.3050407@oracle.com> On 03/06/2013 11:15, Paul Sandoz wrote: > Hi, > > This RFR proposes to remove some duplicate spliterator tests. > > The tests: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java > > are duplicates of: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java > > and the former should be removed. > > Paul. > Make sense to me. -Alan. From Alan.Bateman at oracle.com Mon Jun 3 10:29:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 03 Jun 2013 11:29:19 +0100 Subject: Upgrade to JAXP 1.5 Breaks Existing Apps In-Reply-To: References: Message-ID: <51AC6FFF.7020901@oracle.com> On 02/06/2013 22:05, Ali Ebrahimi wrote: > I update to jdk8b92 and almost all apps deals with xml parsing breaks. > in other word, current default value for XMLConstants.ACCESS_EXTERNAL_DTD > property is empty string. This should be at least change to "file". Yes, the defaults are problematic and are due to be re-examined (but thanks anyway, it's just more evidence that the right thing is to opt-in to have more secure processing rather than requiring the rest of the world to opt-out). I don't know if you are on jdk8-dev but Joe Wang posted a note about this recently: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-May/002554.html -Alan. From david.holmes at oracle.com Mon Jun 3 11:55:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Jun 2013 21:55:50 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> <51A55A64.8060908@oracle.com> Message-ID: <51AC8446.8050802@oracle.com> Hi Otavio, I've put these into a webrev here: http://cr.openjdk.java.net/~dholmes/8015470/webrev/ The changes touch a number of areas but hopefully are trivial enough that we can keep the review on core-libs. As I've put this together I'll be looking for a second reviewer to make sure I didn't mess it up :) On 29/05/2013 9:03 PM, Ot?vio Gon?alves de Santana wrote: > Thank you everyone. > I searched classes with this situation and I find these classes: > > * sun.tools.java.MemberDefinition Fixed > * sun.rmi.rmic.Main Fixed > * sun.tools.jconsole.inspector.Utils One of these could be needed for a null check (params[i].toString()). > * com.sun.jndi.toolkit.dir.SearchFilter Fixed > * javax.swing.text.html.FormView Needed for a null check. Plus the IncompleteAnnotationExample case that doesn't perform the null check. Thanks, David > > > The diffs is in attachment > > > On Tue, May 28, 2013 at 10:31 PM, David Holmes > wrote: > > On 28/05/2013 11:08 PM, Remi Forax wrote: > > On 05/28/2013 02:48 PM, David Holmes wrote: > > Sorry it didn't register that getName() already returns a > String - > hence the toString() is redundant - but minimally so. > > David > > > The second call to toString() also performs an implicit nullcheck > (elementName can not be null). > So if we have to fix something, it's only to remove the call to > toString() after the call to getName(). > > > Good catch Remi! > > Otavio: I don't want to dissuade you from getting involved but as > Remi indicates your suggested change becomes simply > > > - super(annotationType.getName()__.toString() + > + super(annotationType.getName() + > > and this is such a minor change to interpreted performance (the JIT > will remove the toString call) that I don't think it is worth the > process overhead (testing etc) to actually make this change. As I > said in other email sometimes there are non-obvious reasons (like > null checks :) ) that code has to be kept in its current form. > > David > ----- > > > cheers, > R?mi > > > On 28/05/2013 9:15 PM, David Holmes wrote: > > Please see my reply under your original subject line. > > This is not a bug. > > David > > On 28/05/2013 7:37 PM, Ot?vio Gon?alves de Santana wrote: > > diff --git > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > --- > a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > +++ > b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java > > > @@ -55,9 +55,9 @@ > public IncompleteAnnotationException( > Class > annotationType, > String elementName) { > - super(annotationType.getName()__.toString() + > + super(annotationType.getName() + > " missing element " + > - elementName.toString()); > + elementName); > > this.annotationType = annotationType; > this.elementName = elementName; > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > From coleen.phillimore at oracle.com Mon Jun 3 14:08:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 3 Jun 2013 07:08:11 -0700 (PDT) Subject: RFR: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted Message-ID: <51ACA34B.7090506@oracle.com> Summary: The code for this test is fixed now and integrated to TL repo and it passes now. open webrev at http://cr.openjdk.java.net/~coleenp/7124706_jdk/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7124706_jdk Thanks, Coleen From aleksej.efimov at oracle.com Mon Jun 3 14:18:19 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 03 Jun 2013 18:18:19 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51A8B1B1.60108@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, , <517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, , <518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, , , , <519B5444.7060701@oracle.com>, , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>, <51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, <51A49D6B.3020407@oracle.com> , <51A55C70.4070403@oracle.com> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com> Message-ID: <51ACA5AB.5050606@oracle.com> The next version of webrev: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.4/ The list of changes: 1. The test was moved to jdk/test/javax/xml/jaxp/XPath/8009579 2. Throw of InvalidClassException was added 3. Two test cases were added: a) Deserialization of XPathException initialized by ordinary values and serialized by JDK7 build (normal_jdk7.ser file) b) Deserialization of "new XPathException(new Exception()).initCause(null)" XPathException serialized by JDK7 build (twocauses_jdk7.ser file). -Aleksej On 05/31/2013 06:20 PM, Alan Bateman wrote: > On 31/05/2013 14:39, Aleksej Efimov wrote: >> Obviously, we can't throw the ISE - it's not described in docs for >> readObject() method. >> Exceptions suggested by Jason have the following descriptions: >> InvalidClassException: Something is wrong with a class used by >> serialization. >> StreamCorruptedException: Control information in the stream is >> inconsistent. >> I think InvalidClassException more suitable for our case, because we >> have here the problem with inconsistent state of serialized class, >> but not the control information in the stream (invalid stream header, >> invalid type code and etc). >> >> Aleksej > Yes, InvalidClassException would be best. > > I see you've added a serialization/deserialization test (thanks) but > it wouldn't have caught this. What would you think about serializing a > few XPathException instances with a jdk7 build and use the byte stream > in the test to check that they are handled correctly. That would give > more confident that there aren't any other holes. > > -Alan From nils.loodin at oracle.com Mon Jun 3 14:22:31 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Mon, 03 Jun 2013 14:22:31 +0000 Subject: hg: jdk8/tl/jdk: 6526682: JConsole shows negative CPU Usage Message-ID: <20130603142259.C0BA248EE6@hg.openjdk.java.net> Changeset: 33d1376bf725 Author: nloodin Date: 2013-06-03 16:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33d1376bf725 6526682: JConsole shows negative CPU Usage Reviewed-by: alanb, mchung ! src/share/classes/sun/tools/jconsole/SummaryTab.java From ali.ebrahimi1781 at gmail.com Mon Jun 3 14:39:14 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 3 Jun 2013 19:09:14 +0430 Subject: Upgrade to JAXP 1.5 Breaks Existing Apps In-Reply-To: <51AC6FFF.7020901@oracle.com> References: <51AC6FFF.7020901@oracle.com> Message-ID: thanks. On Mon, Jun 3, 2013 at 2:59 PM, Alan Bateman wrote: > On 02/06/2013 22:05, Ali Ebrahimi wrote: > >> I update to jdk8b92 and almost all apps deals with xml parsing breaks. >> in other word, current default value for XMLConstants.ACCESS_EXTERNAL_** >> DTD >> property is empty string. This should be at least change to "file". >> > Yes, the defaults are problematic and are due to be re-examined (but > thanks anyway, it's just more evidence that the right thing is to opt-in to > have more secure processing rather than requiring the rest of the world to > opt-out). > > I don't know if you are on jdk8-dev but Joe Wang posted a note about this > recently: > > http://mail.openjdk.java.net/**pipermail/jdk8-dev/2013-May/**002554.html > > -Alan. > From eric.mccorkle at oracle.com Mon Jun 3 14:48:46 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Mon, 03 Jun 2013 14:48:46 +0000 Subject: hg: jdk8/tl/jdk: 8014834: shell tests don't begin with #!/bin/sh Message-ID: <20130603144858.89CF948EE7@hg.openjdk.java.net> Changeset: 3d4d7ed93731 Author: emc Date: 2013-06-03 10:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d4d7ed93731 8014834: shell tests don't begin with #!/bin/sh Summary: Some shell tests don't begin with the command interpreter line Reviewed-by: alanb, ksrini ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/Locale/data/deflocale.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.sh ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/ClasspathTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/GenericTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/rmi/rmic/newrmic/equivalence/batch.sh ! test/tools/launcher/MultipleJRE.sh From eric.mccorkle at oracle.com Mon Jun 3 14:49:35 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 3 Jun 2013 07:49:35 -0700 (PDT) Subject: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh In-Reply-To: <51AC6AF2.7060809@oracle.com> References: <51A7A03D.2080103@oracle.com> <51A7C880.50700@oracle.com> <51A9E9F7.6020303@oracle.com> <51AC6AF2.7060809@oracle.com> Message-ID: <51ACACFF.6010207@oracle.com> Thanks all, putting the changes in. On 06/03/13 06:07, Alan Bateman wrote: > On 01/06/2013 13:32, Eric McCorkle wrote: >> Thanks, Kumar. Do I have a second? >> > For the jdk repository then only one reviewer is required although in > specialized or complicated areas then having a reviewer that knows the > area well is important. In this case I think you are good to go. > > Just on Kumar's comment then I think a lot of the shell tests start with > "#!" already so I would expect that scripts that check or fix-up > copyright headers should be able to deal with this already. Another > point, and maybe this for follow-on work, is that many of the shell > tests don't have anything so it would be good to fix them up too. We > should of course keep an eye out for opportunities to replace the shell > tests as our ultimate goal should be to get rid of them. > > -Alan. > From kumar.x.srinivasan at oracle.com Mon Jun 3 15:31:58 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 03 Jun 2013 08:31:58 -0700 Subject: RFR: JDK-8015813: add test/tools/pack200/TimeStamp.java to ProblemsList Message-ID: <51ACB6EE.30107@oracle.com> Hi, Please review adding a failing test to ProblemList, until Sherman and I determine the correct fix for the underlying problem in zip/pack200. Thanks Kumar diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -331,6 +331,8 @@ # Tests take too long, on sparcs see 7143279 tools/pack200/CommandLineTests.java solaris-all, macosx-all tools/pack200/Pack200Test.java solaris-all, macosx-all +# 8015666 +tools/pack200/TimeStamp.java generic-all # 8007410 tools/launcher/FXLauncherTest.java linux-all From paul.sandoz at oracle.com Mon Jun 3 15:43:28 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Jun 2013 15:43:28 +0000 Subject: hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API Message-ID: <20130603154340.F1AC048EE8@hg.openjdk.java.net> Changeset: a79e2683eae3 Author: psandoz Date: 2013-06-03 17:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79e2683eae3 8014383: StringJoiner example in class description not in sync with streams API Reviewed-by: alanb ! src/share/classes/java/util/StringJoiner.java From paul.sandoz at oracle.com Mon Jun 3 15:55:21 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Jun 2013 08:55:21 -0700 (PDT) Subject: RFR 8015492: Remove DoubleStream.range methods Message-ID: <03F32FDB-533D-4943-A8D0-9C09E374773F@oracle.com> Hi, The following patch updates DoubleStream to remove the range methods: http://cr.openjdk.java.net/~psandoz/tl/JDK-8015492-rm-DoubleStream.range/webrev/ CCC is in progress. It's best if we let numerical libraries integrate with the Stream API since the library writers are in a better position to design something that meets their use-cases. Paul. From paul.sandoz at oracle.com Mon Jun 3 16:03:54 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Jun 2013 18:03:54 +0200 Subject: RFR 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream Message-ID: <82B38ADC-163C-402F-BEFE-D4563F5C0F83@oracle.com> Hi, The following patch renames the methods IntStream.longs/doubles/LongStream.doubles, as decided by the JSR-335 EG which agreed the new names better convey transformation to another type of primitive stream: http://cr.openjdk.java.net/~psandoz/tl/JDK-8015798-asXxxStream/webrev/ IntStream.longs -> asLongStream IntStream.doubles -> asDoubleStream LongStream.doubles -> asDoubleStream Paul. From paul.sandoz at oracle.com Mon Jun 3 16:09:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 3 Jun 2013 18:09:19 +0200 Subject: RFR 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator Message-ID: Hi, The following patch renames the Spliterators.spliteratorFromIterator methods to Spliterators.iterator, which is more consistent with other methods on the class: http://cr.openjdk.java.net/~psandoz/tl/JDK-8015792-Spliterators.iterator/webrev/ CCC is in progress. Paul. From mike.duigou at oracle.com Mon Jun 3 16:10:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 3 Jun 2013 09:10:25 -0700 Subject: RFR 8015790 Remove duplicate spliterator tests In-Reply-To: <5B7CCFDC-10D1-4D68-BBA6-D391B46C4B92@oracle.com> References: <5B7CCFDC-10D1-4D68-BBA6-D391B46C4B92@oracle.com> Message-ID: <0C76EE41-DDB2-4A4F-851D-54EF5CE8442B@oracle.com> Go ahead! Mike On Jun 3 2013, at 03:15 , Paul Sandoz wrote: > Hi, > > This RFR proposes to remove some duplicate spliterator tests. > > The tests: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java > > are duplicates of: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java > http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java > > and the former should be removed. > > Paul. > > From mike.duigou at oracle.com Mon Jun 3 16:35:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 3 Jun 2013 09:35:23 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51AC3B0A.2000803@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> Message-ID: Looks good to me as well. On Jun 2 2013, at 23:43 , Aleksey Shipilev wrote: > On 05/31/2013 07:44 PM, Aleksey Shipilev wrote: >> [The fields in the same contention group may not be pair-wise isolated] > > Added this to the relevant section. Please see the webrev: > http://cr.openjdk.java.net/~shade/8014966/webrev.05/ > > Martin, David, Mike, please take a final look! > > -Aleksey. From daniel.fuchs at oracle.com Mon Jun 3 16:54:18 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 03 Jun 2013 18:54:18 +0200 Subject: RFR (jaxp): JDK-8013434: Xalan and Xerces internal ObjectFactory need rework Message-ID: <51ACCA3A.9040006@oracle.com> Hi, In order to prepare for modularization, we need to review all the places where META-INF/services is parsed directly. The Xalan and Xerces internal ObjectFactory still have some places where such parsing is implemented. The usual fix in such cases is to replace this 'ad-hoc' parsing by calls to j.u.ServiceLoader. However: 1. The method that parses META-INF in the Xerces ObjectFactory is never used - and therefore this patch simply removes it. 2. The lookup implemented by the Xalan ObjectFactory is an internal undocumented mechanism - which in practice is not useful for the JDK itself (this is basically an internal pluggability layer which allows to replace the default implementation of DTMManager used by the XSLTC transformer). We are therefore proposing to also remove this pluggability - and simply make the JDK always use its own implementation of the DTMManager. The consequence is that defining the system properties com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager and com.sun.org.apache.xml.internal.dtm.DTMManager, or defining concrete implementation classes for XSLTCDTMManager or DTMManager in META-INF/services will no longer have any effect: com.sun.org.apache.xml.internal.dtm.DTMManager will always use its own default implementation, and com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager will also always use its own default implementation. Since there are no changes to the public API we would also like to backport this change to the jdk7 update train in order to keep jdk7 and 8 in sync as much as we can. best regards, -- daniel From martinrb at google.com Mon Jun 3 17:33:52 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Jun 2013 10:33:52 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51AC3B0A.2000803@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> Message-ID: Looks Good To Me. (philosophical note: being able to monitor and relocate objects is one of the strategic advantages of a managed runtime over e.g. C++. With sufficient investment in implementation, the VM could in principle figure out which objects are good to use _as_ padding, and which objects need the padding.) From aleksey.shipilev at oracle.com Mon Jun 3 18:10:34 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 03 Jun 2013 22:10:34 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> Message-ID: <51ACDC1A.5090806@oracle.com> On 06/03/2013 09:33 PM, Martin Buchholz wrote: > Looks Good To Me. Thanks guys! Please sponsor. :) The changeset is here: http://cr.openjdk.java.net/~shade/8014966/8014966.changeset -Aleksey. From mike.duigou at oracle.com Mon Jun 3 18:29:43 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 3 Jun 2013 11:29:43 -0700 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: <51ACDC1A.5090806@oracle.com> References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> <51ACDC1A.5090806@oracle.com> Message-ID: OK, I've got this covered. Will push it to jdk8/tl shortly. Mike On Jun 3 2013, at 11:10 , Aleksey Shipilev wrote: > On 06/03/2013 09:33 PM, Martin Buchholz wrote: >> Looks Good To Me. > > Thanks guys! Please sponsor. :) > > The changeset is here: > http://cr.openjdk.java.net/~shade/8014966/8014966.changeset > > -Aleksey. > From mike.duigou at oracle.com Mon Jun 3 18:32:11 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 03 Jun 2013 18:32:11 +0000 Subject: hg: jdk8/tl/jdk: 8014966: Add the proper Javadoc to @Contended Message-ID: <20130603183231.B809A48EF4@hg.openjdk.java.net> Changeset: 62d3c82b4509 Author: shade Date: 2013-06-03 22:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62d3c82b4509 8014966: Add the proper Javadoc to @Contended Summary: more extensive description. Reviewed-by: dholmes, mduigou, martin ! src/share/classes/sun/misc/Contended.java From xueming.shen at oracle.com Mon Jun 3 19:25:28 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 03 Jun 2013 12:25:28 -0700 Subject: RFR: JDK-8015813: add test/tools/pack200/TimeStamp.java to ProblemsList In-Reply-To: <51ACB6EE.30107@oracle.com> References: <51ACB6EE.30107@oracle.com> Message-ID: <51ACEDA8.8000905@oracle.com> looks fine. On 06/03/2013 08:31 AM, Kumar Srinivasan wrote: > Hi, > > Please review adding a failing test to ProblemList, > until Sherman and I determine the correct fix for the > underlying problem in zip/pack200. > > Thanks > Kumar > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -331,6 +331,8 @@ > # Tests take too long, on sparcs see 7143279 > tools/pack200/CommandLineTests.java solaris-all, macosx-all > tools/pack200/Pack200Test.java solaris-all, macosx-all > +# 8015666 > +tools/pack200/TimeStamp.java generic-all > > # 8007410 > tools/launcher/FXLauncherTest.java linux-all > From nm3mon at gmail.com Mon Jun 3 20:00:29 2013 From: nm3mon at gmail.com (Nabeel Memon) Date: Mon, 3 Jun 2013 16:00:29 -0400 Subject: Fwd: Prohibited package name: java.util.stream In-Reply-To: References: Message-ID: Simply running 'make jdk_util' under the test folder is failing and throwing the same exception: java.lang.SecurityException: Prohibited package name: java.util.stream... for all test sources under under: java/util/stream/test/* and java/util/stream/boottest/* Can anyone please verify if i've missed something or this is a known issue? Nabeel From kumar.x.srinivasan at oracle.com Mon Jun 3 20:21:22 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 03 Jun 2013 20:21:22 +0000 Subject: hg: jdk8/tl/jdk: 8015813: add test/tools/pack200/TimeStamp.java to ProblemsList Message-ID: <20130603202136.520D048EFC@hg.openjdk.java.net> Changeset: f4e2a70260cf Author: ksrini Date: 2013-06-03 13:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4e2a70260cf 8015813: add test/tools/pack200/TimeStamp.java to ProblemsList Reviewed-by: sherman ! test/ProblemList.txt From henry.jen at oracle.com Mon Jun 3 20:33:01 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 03 Jun 2013 13:33:01 -0700 Subject: RFR: 8015522 - CharSequence.codePoints can be faster Message-ID: <51ACFD7D.6020208@oracle.com> Hi, Please review http://cr.openjdk.java.net/~henryjen/tl/8015522.0/webrev/ This webrev is based on previous suggestion from Martin Buchholz while keep the lazy-binding nature without seize the length at construction time. The benchmark shows ~50% performance increase, mainly from reduce of operation, for example, inline block.accept instead of store the character to a local var also helps. Cheers, Henry From martinrb at google.com Mon Jun 3 20:42:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 3 Jun 2013 13:42:58 -0700 Subject: RFR: 8015522 - CharSequence.codePoints can be faster In-Reply-To: <51ACFD7D.6020208@oracle.com> References: <51ACFD7D.6020208@oracle.com> Message-ID: Thanks for the optimization (especially the benchmarking!). Looks Good To Me. On Mon, Jun 3, 2013 at 1:33 PM, Henry Jen wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~henryjen/tl/8015522.0/webrev/ > > This webrev is based on previous suggestion from Martin Buchholz while > keep the lazy-binding nature without seize the length at construction time. > > The benchmark shows ~50% performance increase, mainly from reduce of > operation, for example, inline block.accept instead of store the > character to a local var also helps. > > Cheers, > Henry > From aleksey.shipilev at oracle.com Mon Jun 3 20:45:53 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Jun 2013 00:45:53 +0400 Subject: RFR (S) CR 8014966: Add the proper Javadoc to @Contended In-Reply-To: References: <519B6A0E.5060304@oracle.com> <519DE6A6.3050304@oracle.com> <836DBA0E-C46F-400D-BF01-2301C10A333D@oracle.com> <519E4104.6070007@oracle.com> <1EED3F39-DF33-4F3B-AE6F-3A10D67095B0@oracle.com> <519E4816.1080500@oracle.com> <519E486F.8060407@oracle.com> <519EAD3C.7080803@oracle.com> <51A35530.7010404@oracle.com> <51A3F632.90304@oracle.com> <51A508E9.9070405@oracle.com> <51A52104.10509@oracle.com> <51A5E46C.5030908@oracle.com> <51A8523A.2040304@gmail.com> <51A8C54A.4020008@oracle.com> <51AC3B0A.2000803@oracle.com> <51ACDC1A.5090806@oracle.com> Message-ID: <51AD0081.607@oracle.com> Thanks! On 06/03/2013 10:29 PM, Mike Duigou wrote: > OK, I've got this covered. Will push it to jdk8/tl shortly. > > Mike > > On Jun 3 2013, at 11:10 , Aleksey Shipilev wrote: > >> On 06/03/2013 09:33 PM, Martin Buchholz wrote: >>> Looks Good To Me. >> >> Thanks guys! Please sponsor. :) >> >> The changeset is here: >> http://cr.openjdk.java.net/~shade/8014966/8014966.changeset >> >> -Aleksey. >> > From jonathan.gibbons at oracle.com Mon Jun 3 23:23:17 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 03 Jun 2013 23:23:17 +0000 Subject: hg: jdk8/tl/langtools: 8013405: DocLint should support
  • Message-ID: <20130603232321.C159F48F00@hg.openjdk.java.net> Changeset: 391f97e270c2 Author: jjg Date: 2013-06-03 16:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/391f97e270c2 8013405: DocLint should support
  • Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/ListTagsTest.out From brent.christian at oracle.com Mon Jun 3 23:34:17 2013 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 03 Jun 2013 16:34:17 -0700 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> <51AA286D.9020306@cs.oswego.edu> <51AC3010.3060609@oracle.com> Message-ID: <51AD27F9.50209@oracle.com> Hi, Paul If a HashMap is created via serialization or clone(), we don't check if the table needs resizing when adding entries, but still need to check if a bin should be converted to a TreeBin. In this case, putForCreate() calls createEntry() directly, instead of addEntry(). Thanks, -Brent On 6/3/13 12:56 AM, Paul Sandoz wrote: > Hi Brent, > > A minor thing: take it or leave it :-) > > In HashMap: > > 2207 void addEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { > 2208 // assert key != null; > 2209 if ((size >= threshold) && (null != table[bucketIndex])) { > 2210 resize(2 * table.length); > 2211 hash = hash(key); > 2212 bucketIndex = indexFor(hash, table.length); > 2213 } > 2214 createEntry(hash, key, value, bucketIndex, checkIfNeedTree); > 2215 } > > You could re-verify the bucket size if the table is resized rather than in createEntry, since that AFAICT is the only case where conditions after the call to addEntry might change. > > Pau. > From lana.steuck at oracle.com Mon Jun 3 23:59:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:59:00 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130603235917.4C80C48F08@hg.openjdk.java.net> Changeset: 827b59af45f3 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/827b59af45f3 Added tag jdk8-b91 for changeset e3065fb07877 ! .hgtags Changeset: 1ab5d8d6eab8 Author: katleman Date: 2013-05-29 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1ab5d8d6eab8 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: a6596a06e10b Author: katleman Date: 2013-05-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a6596a06e10b Added tag jdk8-b92 for changeset 1ab5d8d6eab8 ! .hgtags Changeset: f117a66f337c Author: lana Date: 2013-06-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f117a66f337c Merge From lana.steuck at oracle.com Mon Jun 3 23:58:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:58:51 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20130603235853.1796E48F04@hg.openjdk.java.net> Changeset: eea249c1ecee Author: erikj Date: 2013-05-21 13:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/eea249c1ecee 8014508: Fix log levels in make Reviewed-by: tbell ! NewMakefile.gmk ! common/autoconf/spec.gmk.in Changeset: e83abb0a04ab Author: katleman Date: 2013-05-21 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e83abb0a04ab Merge Changeset: cb51fb4789ac Author: andrew Date: 2013-05-22 13:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cb51fb4789ac 8015087: Provide debugging information for programs Summary: Enable debugging info on programs in OpenJDK builds Reviewed-by: erikj ! common/makefiles/NativeCompilation.gmk Changeset: f089df41bff5 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f089df41bff5 Added tag jdk8-b91 for changeset cb51fb4789ac ! .hgtags Changeset: e247ee3924d5 Author: erikj Date: 2013-05-22 17:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e247ee3924d5 8014514: Fix jvm args for sjavac Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh Changeset: e7c09a983c3c Author: erikj Date: 2013-05-28 08:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e7c09a983c3c 8007129: build-infra Add configure --with-jtreg option for location of JTREG Reviewed-by: tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3a36c926a7aa Author: katleman Date: 2013-05-28 17:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3a36c926a7aa Merge Changeset: 46be9eb242d1 Author: katleman Date: 2013-05-30 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/46be9eb242d1 Added tag jdk8-b92 for changeset 3a36c926a7aa ! .hgtags From lana.steuck at oracle.com Mon Jun 3 23:58:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:58:57 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130603235904.7A98F48F06@hg.openjdk.java.net> Changeset: dee23cce5235 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/dee23cce5235 Added tag jdk8-b91 for changeset 6b9f41203800 ! .hgtags Changeset: 1c7481ac7fe0 Author: katleman Date: 2013-05-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1c7481ac7fe0 Added tag jdk8-b92 for changeset dee23cce5235 ! .hgtags Changeset: 7e105c2f3167 Author: lana Date: 2013-06-03 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7e105c2f3167 Merge From lana.steuck at oracle.com Mon Jun 3 23:58:54 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:58:54 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130603235908.E1D2148F07@hg.openjdk.java.net> Changeset: a0f604766ca1 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a0f604766ca1 Added tag jdk8-b91 for changeset 0bb1a9fa56b0 ! .hgtags Changeset: 7386eca865e1 Author: katleman Date: 2013-05-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7386eca865e1 Added tag jdk8-b92 for changeset a0f604766ca1 ! .hgtags From lana.steuck at oracle.com Mon Jun 3 23:58:52 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:58:52 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130603235855.52BFC48F05@hg.openjdk.java.net> Changeset: 717aa26f8e0a Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/717aa26f8e0a Added tag jdk8-b91 for changeset 8f7ffb296385 ! .hgtags Changeset: 8dc9d7ccbb2d Author: katleman Date: 2013-05-30 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8dc9d7ccbb2d Added tag jdk8-b92 for changeset 717aa26f8e0a ! .hgtags From lana.steuck at oracle.com Mon Jun 3 23:59:21 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:59:21 +0000 Subject: hg: jdk8/tl/hotspot: 42 new changesets Message-ID: <20130604000052.5BF3848F0A@hg.openjdk.java.net> Changeset: ad47de214f0c Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad47de214f0c Added tag jdk8-b91 for changeset 7cbdf0e3725c ! .hgtags Changeset: 7ec426e29e4c Author: amurillo Date: 2013-05-17 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ec426e29e4c 8014760: new hotspot build - hs25-b34 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f49e0508a38a Author: rbackman Date: 2013-05-15 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f49e0508a38a 4965252: JvmtiExport::post_raw_field_modification jni ref handling is odd Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiExport.cpp Changeset: 243469d929e6 Author: ctornqvi Date: 2013-05-16 15:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/243469d929e6 8008169: test/runtime/7158804/Test7158804.sh has bad copyright header Summary: Re-wrote test in Java in addition to fixing the Copyright notice. Also reviewed by leonid.mesnik at oracle.com Reviewed-by: coleenp, ctornqvi Contributed-by: Mikhailo Seledtsov - test/runtime/7158804/Test7158804.sh + test/runtime/CommandLine/ConfigFileParsing.java Changeset: 17db82f22f1e Author: ctornqvi Date: 2013-05-16 17:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17db82f22f1e 8014511: runtime/RedefineObject/TestRedefineObject.java has incorrect classname in @run tag Summary: Corrected the class name Reviewed-by: coleenp, ctornqvi, hseigel Contributed-by: Mikhailo Seledtsov ! test/runtime/RedefineObject/TestRedefineObject.java Changeset: 78332b46e604 Author: kevinw Date: 2013-05-16 12:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78332b46e604 6313816: SA: jstack -m fails on Win32 : UnalignedAddressException Reviewed-by: sla, poonam - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/amd64/WindowsAMD64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java ! make/sa.files Changeset: 205dd30230e1 Author: shade Date: 2013-05-17 01:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/205dd30230e1 8012939: @Contended doesn't work correctly with inheritance Summary: Fix instance_size miscalculation. Reviewed-by: jrose, kvn ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/Inheritance1.java Changeset: b334821dad92 Author: dholmes Date: 2013-05-16 21:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b334821dad92 Merge Changeset: 50e9396d5257 Author: shade Date: 2013-05-17 01:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50e9396d5257 8014509: @Contended: explicit default value behaves differently from the implicit value Summary: Treat the empty string as the default value tag Reviewed-by: kvn, twisti ! src/share/vm/classfile/classFileParser.cpp + test/runtime/contended/DefaultValue.java Changeset: 074ba6269cf4 Author: dholmes Date: 2013-05-16 22:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/074ba6269cf4 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java Changeset: 1ba508fcd3e2 Author: dholmes Date: 2013-05-16 23:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1ba508fcd3e2 Merge Changeset: 6ce351ac7339 Author: rdurbin Date: 2013-05-17 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ce351ac7339 7145527: sscanf must use a length in the format string Summary: Remove dead code containing last call to scanf with no string length specifier Reviewed-by: dcubed, coleenp ! src/share/vm/utilities/debug.cpp Changeset: a250c89cf9e3 Author: dcubed Date: 2013-05-17 08:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a250c89cf9e3 Merge Changeset: b5be63340698 Author: dcubed Date: 2013-05-17 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5be63340698 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! src/share/vm/classfile/classFileParser.cpp - test/runtime/7158804/Test7158804.sh Changeset: 386b77bf6427 Author: dcubed Date: 2013-05-17 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/386b77bf6427 Merge - make/bsd/makefiles/launcher.make - make/linux/makefiles/launcher.make - make/solaris/makefiles/launcher.make - make/windows/makefiles/launcher.make - src/os/posix/launcher/java_md.c - src/os/posix/launcher/java_md.h - src/os/posix/launcher/launcher.script - src/os/windows/launcher/java_md.c - src/os/windows/launcher/java_md.h - src/share/tools/launcher/java.c - src/share/tools/launcher/java.h - src/share/tools/launcher/jli_util.c - src/share/tools/launcher/jli_util.h - src/share/tools/launcher/wildcard.c - src/share/tools/launcher/wildcard.h - src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp Changeset: a5d6f0c3585f Author: iklam Date: 2013-05-18 20:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5d6f0c3585f 8014262: PrintStringTableStatistics should include more footprint info Summary: Added info for the string/symbol objects and the hash entries Reviewed-by: coleenp, rbackman ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5e3573e08a83 Author: shade Date: 2013-05-20 15:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e3573e08a83 8014871: Move @Contended regression tests to the same place Summary: Move the missing test to appropriate location. Reviewed-by: dholmes, sla - test/runtime/8003985/Test8003985.java + test/runtime/contended/Basic.java Changeset: bbddfb08190f Author: shade Date: 2013-05-20 23:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbddfb08190f 8014878: Clean up class field layout code Summary: rename/remove local variables, re-arrange instance_size calculation, more comments. Reviewed-by: kvn, coleenp ! src/share/vm/classfile/classFileParser.cpp Changeset: 293b99787401 Author: dholmes Date: 2013-05-14 07:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/293b99787401 8014460: Need to check for non-empty EXT_LIBS_PATH before using it Reviewed-by: tbell, collins, sla, coleenp ! make/bsd/makefiles/arm.make ! make/linux/makefiles/arm.make Changeset: 26579ac80ce9 Author: bpittore Date: 2013-05-15 23:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26579ac80ce9 8014669: arch specific flags not passed to some link commands Summary: EXTRA_CFLAGS does not propagate to saproc and jsig makefiles Reviewed-by: dholmes, tbell, collins ! make/linux/makefiles/jsig.make ! make/linux/makefiles/saproc.make Changeset: f8c833eb2a5f Author: jiangli Date: 2013-05-20 13:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8c833eb2a5f Merge Changeset: c838b672691c Author: jiangli Date: 2013-05-23 13:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c838b672691c Merge Changeset: 91eba9f82325 Author: anoll Date: 2013-05-16 15:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91eba9f82325 8012371: Adjust Tiered compile threshold according to available space in code cache Summary: Added command line parameter to define a threshold at which C1 compilation threshold for is increased. Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/advancedThresholdPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ec922e5c545a Author: anoll Date: 2013-05-22 10:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec922e5c545a 8012312: hsdis fails to compile with binutils-2.23.2 Summary: added to header file to make hsdis compile with binutils 2.23.* Reviewed-by: kvn, twisti ! src/share/tools/hsdis/hsdis.c Changeset: b4907b24ed48 Author: twisti Date: 2013-05-22 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4907b24ed48 Merge Changeset: 1682bec79205 Author: kvn Date: 2013-05-22 09:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1682bec79205 8014811: loopTransform.cpp assert(cmp_end->in(2) == limit) failed Summary: Stop current iteration of loop opts if partial_peel() failed and it created node clones outside processed loop. Reviewed-by: roland ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 71a2d06b9c2b Author: kvn Date: 2013-05-22 17:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71a2d06b9c2b Merge Changeset: 3f281b313240 Author: kvn Date: 2013-05-22 18:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f281b313240 8010927: Kitchensink crashed with SIGSEGV, Problematic frame: v ~StubRoutines::checkcast_arraycopy Summary: Changed gen_write_ref_array_post_barrier() code on x64 to pass start address and number of copied oop elements. In generate_checkcast_copy() skip post barrier code if no elements are copied. Reviewed-by: roland ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp + test/compiler/8010927/Test8010927.java Changeset: 01e51113b4f5 Author: anoll Date: 2013-05-23 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01e51113b4f5 8014430: JRE crashes instead of stop compilation on full Code Cache. Internal Error (c1_Compiler.cpp:87) Summary: Disable client compiler and switch to interpreter if there is not enough free space in the code cache. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp Changeset: 59e18b573605 Author: twisti Date: 2013-05-23 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59e18b573605 Merge Changeset: 001ec9515f84 Author: ehelin Date: 2013-05-17 11:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/001ec9515f84 8014277: Remove ObjectClosure as base class for BoolObjectClosure Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 2138a2c14831 Author: jwilhelm Date: 2013-05-19 20:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2138a2c14831 Merge ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 10f759898d40 Author: tamao Date: 2013-05-20 10:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10f759898d40 7186737: Unable to allocate bit maps or card tables for parallel gc for the requested heap Summary: Print helpful error message when VM aborts due to inability of allocating bit maps or card tables Reviewed-by: jmasa, stefank Contributed-by: tamao ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 2b1a9d972fc2 Author: jmasa Date: 2013-05-20 22:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b1a9d972fc2 8014862: Add fast Metasapce capacity and used per MetadataType Reviewed-by: ehelin, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 28e53b8db94f Author: brutisso Date: 2013-05-21 08:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28e53b8db94f 7066063: CMS: "Conservation Principle" assert failed Summary: Add call to coalBirth() in CompactibleFreeListSpace::reset() Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 5ed122fbd0ef Author: brutisso Date: 2013-05-21 10:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ed122fbd0ef Merge Changeset: 6702da6b6082 Author: tschatzl Date: 2013-05-21 11:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6702da6b6082 8014405: G1: PerRegionTable::fl_mem_size() calculates size of the free list using wrong element sizes Summary: Instead of using a simple sizeof(), ask the PerRegionTable class about its size when iterating over the free list. Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/prims/jni.cpp Changeset: 7c5a1b62f53d Author: brutisso Date: 2013-05-22 08:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c5a1b62f53d 8014971: Minor code cleanup of the freelist management Reviewed-by: jwilhelm, jmasa, tschatzl ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp Changeset: 62890ed7e2a8 Author: jwilhelm Date: 2013-05-24 09:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62890ed7e2a8 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 38da9f4f6709 Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38da9f4f6709 Merge - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java - agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java - test/runtime/7158804/Test7158804.sh - test/runtime/8003985/Test8003985.java Changeset: 092018493d3b Author: amurillo Date: 2013-05-24 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/092018493d3b Added tag hs25-b34 for changeset 38da9f4f6709 ! .hgtags Changeset: 573d86d412cd Author: katleman Date: 2013-05-30 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/573d86d412cd Added tag jdk8-b92 for changeset 092018493d3b ! .hgtags From lana.steuck at oracle.com Mon Jun 3 23:59:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:59:01 +0000 Subject: hg: jdk8/tl/langtools: 7 new changesets Message-ID: <20130603235930.C178B48F09@hg.openjdk.java.net> Changeset: 4830d661c4f9 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4830d661c4f9 Added tag jdk8-b91 for changeset 997c0fae2b12 ! .hgtags Changeset: 58eace4d997f Author: erikj Date: 2013-05-28 08:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58eace4d997f 8012566: Replace find, rm, printf and similar with their proper variables Reviewed-by: tbell ! makefiles/BuildLangtools.gmk Changeset: 3597773628a4 Author: katleman Date: 2013-05-28 17:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3597773628a4 Merge Changeset: 149890642a0e Author: katleman Date: 2013-05-29 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/149890642a0e 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! test/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java Changeset: 023e9a614d26 Author: katleman Date: 2013-05-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/023e9a614d26 Added tag jdk8-b92 for changeset 149890642a0e ! .hgtags Changeset: 8258f84a8649 Author: lana Date: 2013-06-03 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8258f84a8649 Merge Changeset: 7a4fd1076b15 Author: lana Date: 2013-06-03 16:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a4fd1076b15 Merge From lana.steuck at oracle.com Mon Jun 3 23:59:10 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 03 Jun 2013 23:59:10 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20130604000125.5D10348F0B@hg.openjdk.java.net> Changeset: 2868607646a0 Author: erikj Date: 2013-05-21 17:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2868607646a0 8011346: build-infra: While Constructing Javadoc information, JSpinner.java error: package sun.util.locale.provider does not exist Reviewed-by: dholmes, tbell, naoto ! makefiles/GensrcSwing.gmk Changeset: b61632814be2 Author: katleman Date: 2013-05-21 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b61632814be2 Merge Changeset: f559fadbf491 Author: andrew Date: 2013-05-22 13:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f559fadbf491 8015087: Provide debugging information for programs Summary: Add missing debug info to unpack200 and jexec Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk Changeset: 88d6a20672ac Author: erikj Date: 2013-05-22 10:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88d6a20672ac 8014970: Use open man pages for non commercial builds Reviewed-by: omajid, tbell ! makefiles/Images.gmk Changeset: 169451cf0cc5 Author: erikj Date: 2013-05-22 15:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/169451cf0cc5 Merge Changeset: fbd926b20201 Author: katleman Date: 2013-05-23 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbd926b20201 Added tag jdk8-b91 for changeset 169451cf0cc5 ! .hgtags Changeset: a2a2a91075ad Author: katleman Date: 2013-05-29 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2a2a91075ad 8015525: JDK8 b91 source with GPL header errors Reviewed-by: dholmes, lancea ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/MapTest.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/MethodReferenceTestKinds.java ! test/jdk/lambda/MethodReferenceTestSueCase1.java ! test/jdk/lambda/MethodReferenceTestSueCase2.java ! test/jdk/lambda/MethodReferenceTestSueCase4.java ! test/jdk/lambda/separate/AttributeInjector.java ! test/jdk/lambda/separate/ClassFile.java ! test/jdk/lambda/separate/ClassFilePreprocessor.java ! test/jdk/lambda/separate/ClassToInterfaceConverter.java ! test/jdk/lambda/separate/Compiler.java ! test/jdk/lambda/separate/DirectedClassLoader.java ! test/jdk/lambda/separate/SourceModel.java ! test/jdk/lambda/separate/TestHarness.java ! test/jdk/lambda/vm/DefaultMethodRegressionTests.java ! test/jdk/lambda/vm/DefaultMethodsTest.java ! test/jdk/lambda/vm/InterfaceAccessFlagsTest.java Changeset: 3c08c9ebd1fb Author: katleman Date: 2013-05-30 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c08c9ebd1fb Added tag jdk8-b92 for changeset a2a2a91075ad ! .hgtags Changeset: 1fd682e7110b Author: lana Date: 2013-06-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fd682e7110b Merge From jonathan.gibbons at oracle.com Tue Jun 4 00:09:31 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 04 Jun 2013 00:09:31 +0000 Subject: hg: jdk8/tl/langtools: 8006615: [doclint] move remaining messages into resource bundle Message-ID: <20130604000934.BA9B048F0C@hg.openjdk.java.net> Changeset: 242bcad5be74 Author: jjg Date: 2013-06-03 17:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/242bcad5be74 8006615: [doclint] move remaining messages into resource bundle Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ResourceTest.java ! test/tools/doclint/tool/RunTest.java From jonathan.gibbons at oracle.com Tue Jun 4 00:24:56 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 04 Jun 2013 00:24:56 +0000 Subject: hg: jdk8/tl/langtools: 8007687: javadoc -X does not include -Xdoclint Message-ID: <20130604002459.86C9948F0D@hg.openjdk.java.net> Changeset: 019063968164 Author: jjg Date: 2013-06-03 17:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/019063968164 8007687: javadoc -X does not include -Xdoclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java + test/com/sun/javadoc/testXOption/TestXOption.java From brian.burkhalter at oracle.com Tue Jun 4 00:27:38 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 3 Jun 2013 17:27:38 -0700 Subject: Measuring performance changes from applying 4837946 patch Message-ID: I have spent some time trying to assess the performance improvements to be accrued by applying the patch http://cr.openjdk.java.net/~bpb/4837946/ which I previously posted for code review. It is clear from the literature and from analysis of the algorithms involved that significant performance improvements should be obtained as the bit lengths of the factors increase. This also has been verified by other core-libs-dev members in their own testing. I have indeed observed performance improvements but at vastly different algorithm thresholds for the bit lengths involved than those which are currently defined by the thresholds in the updated BigInteger class. I am posting this message as a sort of "sanity test" of my performance evaluation attempts as I think it is more likely that any unusual results are due to my measurements as opposed to the tested code itself. For performance testing I have thus far exclusively used my regular development platform which is a 2.8 GHz MacBookPro5,3 [1] running Mac OS 10.7.5 (Lion) and upgraded, for what it matters, to 8 GB of RAM and a 7200 RPM HDD. For micro-benchmarking I have primarily used the Java Microbenchmark Harness (JMH) [2], although I wrote some standalone test code as well. Also, I constrained testing for the most part to the single-threaded case, although relative performance between algorithms was similar for two threads. I am only going to quote a couple of results here pending feedback of a more general nature about performance testing. 1) Firstly, for single-threaded multiplication of a 1601-bit BigInteger by a 2000-bit BitInteger I am seeing that the Karatsuba algorithm is 60-70% slower than the standard algorithm, and 3-way Toom-Cook is slower still. The 60-70% ratio is consistent between the JMH-based tests and the standalone tests. A bit length of 1600 for both factors is the threshold at which Karatsuba multiplication should kick in. 2) Based on a number of runs with different bit lengths, I did not see the Karatsuba algorithm start to outperform the standard algorithm until bit lengths somewhere between 10400 and 12800. This is about 6.5-8 times the current threshold. Note that these numbers are based on a modified version of BigInteger I created for testing. This modified version contains three public methods multiply_standard(), multiply_karatsuba(), and multiply_toom_cook(). The first of these is the usual standard algorithm. The second uses the Karatsuba algorithm until EITHER factor is below the threshold, then devolves to the standard algorithm. The third uses the Toom-Cook algorithm until BOTH factors are below the threshold and then uses the standard algorithm. The purpose of using these different methods is to avoid mixing the accelerated algorithms within a single test. Being quite skeptical of my own results, the questions I have at this point are: A) Is there some particular approach that should be used in testing these algorithms for relative performance? B) Could there be something platform-dependent happening? C) As currently implemented, the relative performance between algorithms should be unaffected by thread count, correct? Any suggestions would be appreciated. Thanks, Brian [1] http://www.everymac.com/systems/apple/macbook_pro/specs/macbook-pro-core-2-duo-2.8-aluminum-15-mid-2009-sd-unibody-specs.html [2] http://openjdk.java.net/projects/code-tools/jmh/ From huizhe.wang at oracle.com Tue Jun 4 04:58:15 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 03 Jun 2013 21:58:15 -0700 Subject: RFR (jaxp): JDK-8013434: Xalan and Xerces internal ObjectFactory need rework In-Reply-To: <51ACCA3A.9040006@oracle.com> References: <51ACCA3A.9040006@oracle.com> Message-ID: <51AD73E7.4040208@oracle.com> Hi Daniel, The patch looks good. Thanks for cleaning this up. The patch can be applied to JDK7 with no change. Best regards, Joe On 6/3/2013 9:54 AM, Daniel Fuchs wrote: > Hi, > > In order to prepare for modularization, we need to review all > the places where META-INF/services is parsed directly. > > The Xalan and Xerces internal ObjectFactory still have some > places where such parsing is implemented. > The usual fix in such cases is to replace this 'ad-hoc' parsing > by calls to j.u.ServiceLoader. > > However: > > 1. The method that parses META-INF in the Xerces ObjectFactory is > never used - and therefore this patch simply removes it. > > 2. The lookup implemented by the Xalan ObjectFactory is an internal > undocumented mechanism - which in practice is not useful for > the JDK itself (this is basically an internal pluggability > layer which allows to replace the default implementation of > DTMManager used by the XSLTC transformer). > > We are therefore proposing to also remove this pluggability - and > simply make the JDK always use its own implementation of the > DTMManager. > > The consequence is that defining the system properties > com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager and > com.sun.org.apache.xml.internal.dtm.DTMManager, or defining > concrete implementation classes for XSLTCDTMManager or DTMManager > in META-INF/services will no longer have any effect: > > com.sun.org.apache.xml.internal.dtm.DTMManager will always use > its own default implementation, and > com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager will > also always use its own default implementation. > > > > Since there are no changes to the public API we would also like to > backport this change to the jdk7 update train in order to keep jdk7 > and 8 in sync as much as we can. > > best regards, > > -- daniel > > > > From huizhe.wang at oracle.com Tue Jun 4 05:11:46 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 03 Jun 2013 22:11:46 -0700 Subject: RFR (jaxp): JDK-8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 Message-ID: <51AD7712.800@oracle.com> Hi, The default restriction in JDK8 is too strict. We've heard enough of complaints and decided to remove it. Below is the quick fix to remove the default restriction setting. Also, there was a bug in XMLSchemaFactory's setFeature method where the access properties should be set only when secure processing is true. webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8015630/webrev/ Tests pass after removing restriction check. Thanks, Joe From Alan.Bateman at oracle.com Tue Jun 4 05:52:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 06:52:05 +0100 Subject: RFR 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream In-Reply-To: <82B38ADC-163C-402F-BEFE-D4563F5C0F83@oracle.com> References: <82B38ADC-163C-402F-BEFE-D4563F5C0F83@oracle.com> Message-ID: <51AD8085.3000900@oracle.com> On 03/06/2013 17:03, Paul Sandoz wrote: > Hi, > > The following patch renames the methods IntStream.longs/doubles/LongStream.doubles, as decided by the JSR-335 EG which agreed the new names better convey transformation to another type of primitive stream: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015798-asXxxStream/webrev/ > > IntStream.longs -> asLongStream > IntStream.doubles -> asDoubleStream > LongStream.doubles -> asDoubleStream > > Paul. Looks good to me. -Alan From Alan.Bateman at oracle.com Tue Jun 4 05:55:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jun 2013 22:55:20 -0700 (PDT) Subject: Fwd: Prohibited package name: java.util.stream In-Reply-To: References: Message-ID: <51AD8148.8080102@oracle.com> On 03/06/2013 21:00, Nabeel Memon wrote: > Simply running 'make jdk_util' under the test folder is failing and > throwing the same exception: > > java.lang.SecurityException: Prohibited package name: java.util.stream... > > for all test sources under under: > > java/util/stream/test/* and java/util/stream/boottest/* > > > Can anyone please verify if i've missed something or this is a known issue? > > > > Nabeel The stream tests add classes on the boot class path and need the latest jtreg to get that support. This means building jtreg yourself and I see you've started a discussion on jtreg-use about that. -Alan From Alan.Bateman at oracle.com Tue Jun 4 06:00:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jun 2013 23:00:05 -0700 (PDT) Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51AC8446.8050802@oracle.com> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> <51A55A64.8060908@oracle.com> <51AC8446.8050802@oracle.com> Message-ID: <51AD8265.2000805@oracle.com> On 03/06/2013 12:55, David Holmes wrote: > Hi Otavio, > > I've put these into a webrev here: > > http://cr.openjdk.java.net/~dholmes/8015470/webrev/ > > The changes touch a number of areas but hopefully are trivial enough > that we can keep the review on core-libs. As I've put this together > I'll be looking for a second reviewer to make sure I didn't mess it up :) Looks okay to me too. Ot?vio - I don't see you on the list of signatories to the OCA. Have you been through the "How to contribute" page [1]? -Alan. [1] http://openjdk.java.net/contribute/ From david.holmes at oracle.com Tue Jun 4 06:06:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Jun 2013 16:06:19 +1000 Subject: 8015470: (ann) IncompleteAnnotationException does not need to call toString In-Reply-To: <51AD8265.2000805@oracle.com> References: <51A491E6.9080707@oracle.com> <51A4A7A5.8020504@oracle.com> <51A4AC3F.2050200@univ-mlv.fr> <51A55A64.8060908@oracle.com> <51AC8446.8050802@oracle.com> <51AD8265.2000805@oracle.com> Message-ID: <51AD83DB.4030206@oracle.com> Hi Alan, On 4/06/2013 4:00 PM, Alan Bateman wrote: > On 03/06/2013 12:55, David Holmes wrote: >> Hi Otavio, >> >> I've put these into a webrev here: >> >> http://cr.openjdk.java.net/~dholmes/8015470/webrev/ >> >> The changes touch a number of areas but hopefully are trivial enough >> that we can keep the review on core-libs. As I've put this together >> I'll be looking for a second reviewer to make sure I didn't mess it up :) > Looks okay to me too. > > Ot?vio - I don't see you on the list of signatories to the OCA. Have you > been through the "How to contribute" page [1]? I've directed Otavio to the OCA but as you know the OCA is not required for very simple patches [1] and I think deleting a few toString()s qualifies. David [1] http://openjdk.java.net/bylaws#participant > -Alan. > > [1] http://openjdk.java.net/contribute/ From Alan.Bateman at oracle.com Tue Jun 4 06:54:32 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jun 2013 23:54:32 -0700 (PDT) Subject: RFR (jaxp): JDK-8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 In-Reply-To: <51AD7712.800@oracle.com> References: <51AD7712.800@oracle.com> Message-ID: <51AD8F28.80808@oracle.com> On 04/06/2013 06:11, huizhe wang wrote: > Hi, > > The default restriction in JDK8 is too strict. We've heard enough of > complaints and decided to remove it. Below is the quick fix to remove > the default restriction setting. > > Also, there was a bug in XMLSchemaFactory's setFeature method where > the access properties should be set only when secure processing is true. > > webrevs: > http://cr.openjdk.java.net/~joehw/jdk8/8015630/webrev/ > > Tests pass after removing restriction check. This seems the most sensible thing to do and the changes look okay to me. -Alan. From paul.sandoz at oracle.com Tue Jun 4 07:45:35 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Jun 2013 09:45:35 +0200 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: <51AD27F9.50209@oracle.com> References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> <51AA286D.9020306@cs.oswego.edu> <51AC3010.3060609@oracle.com> <51AD27F9.50209@oracle.com> Message-ID: Hi, On Jun 4, 2013, at 1:34 AM, Brent Christian wrote: > Hi, Paul > > If a HashMap is created via serialization or clone(), we don't check if the table needs resizing when adding entries, but still need to check if a bin should be converted to a TreeBin. In this case, putForCreate() calls createEntry() directly, instead of addEntry(). > But putForCreate calculates "checkIfNeedTree": 1161 if (table[i] instanceof Entry) { 1162 int listSize = 0; 1163 Entry e = (Entry) table[i]; 1164 for (; e != null; e = (Entry)e.next) { 1165 Object k; 1166 if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { 1167 e.value = value; 1168 return; 1169 } 1170 listSize++; 1171 } 1172 // Didn't find, fall through to createEntry(). 1173 // Check for conversion to TreeBin done via createEntry(). 1174 checkIfNeedTree = listSize >= TreeBin.TREE_THRESHOLD; 1175 } else if (table[i] != null) { ... 1186 1187 createEntry(hash, key, value, i, checkIfNeedTree); 1188 } So the call to createEntry is just recalculating the same "listSize" value: 2232 void createEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { ... 2239 if (checkIfNeedTree) { 2240 int listSize = 0; 2241 for (e = (Entry) table[bucketIndex]; e != null; e = (Entry)e.next) { 2242 listSize++; 2243 if (listSize >= TreeBin.TREE_THRESHOLD) { // Convert to TreeBin 2244 if (comparableClassFor(key) != null) { 2245 TreeBin t = new TreeBin(); 2246 t.populate((Entry)table[bucketIndex]); 2247 table[bucketIndex] = t; 2248 } 2249 break; 2250 } 2251 } 2252 } Paul. > Thanks, > -Brent > > On 6/3/13 12:56 AM, Paul Sandoz wrote: >> Hi Brent, >> >> A minor thing: take it or leave it :-) >> >> In HashMap: >> >> 2207 void addEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { >> 2208 // assert key != null; >> 2209 if ((size >= threshold) && (null != table[bucketIndex])) { >> 2210 resize(2 * table.length); >> 2211 hash = hash(key); >> 2212 bucketIndex = indexFor(hash, table.length); >> 2213 } >> 2214 createEntry(hash, key, value, bucketIndex, checkIfNeedTree); >> 2215 } >> >> You could re-verify the bucket size if the table is resized rather > than in createEntry, since that AFAICT is the only case where conditions > after the call to addEntry might change. >> >> Pau. >> From staffan.larsen at oracle.com Tue Jun 4 07:45:42 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 04 Jun 2013 07:45:42 +0000 Subject: hg: jdk8/tl/jdk: 8015856: Remove java/lang/instrument/IsModifiableClassAgent.java from ProblemList.txt Message-ID: <20130604074603.0396A48F1A@hg.openjdk.java.net> Changeset: 25cf25fb8c68 Author: sla Date: 2013-06-04 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25cf25fb8c68 8015856: Remove java/lang/instrument/IsModifiableClassAgent.java from ProblemList.txt Reviewed-by: dholmes ! test/ProblemList.txt From paul.sandoz at oracle.com Tue Jun 4 07:56:50 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Jun 2013 09:56:50 +0200 Subject: RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees In-Reply-To: References: <51911943.7000106@oracle.com> <519D2F9D.9010203@oracle.com> <519E09A7.7040304@cs.oswego.edu> <519E67AF.7090504@oracle.com> <51A48241.2030507@cs.oswego.edu> <51A50DA1.8060502@oracle.com> <9D468A1A-A007-4B53-9DCE-7896FC91E50F@oracle.com> <51A64B64.5080209@oracle.com> <51A66950.3020009@oracle.com> <51A8AF47.3000802@oracle.com> <51AA286D.9020306@cs.oswego.edu> <51AC3010.3060609@oracle.com> <51AD27F9.50209@oracle.com> Message-ID: <97719A87-0F9F-4589-8033-248971D50208@oracle.com> I forgot to say please don't let this hold up getting the patch into TL. I think it more important to get the code in then iterate on it. Paul. On Jun 4, 2013, at 9:45 AM, Paul Sandoz wrote: > Hi, > > On Jun 4, 2013, at 1:34 AM, Brent Christian wrote: > >> Hi, Paul >> >> If a HashMap is created via serialization or clone(), we don't check if the table needs resizing when adding entries, but still need to check if a bin should be converted to a TreeBin. In this case, putForCreate() calls createEntry() directly, instead of addEntry(). >> > > But putForCreate calculates "checkIfNeedTree": > 1161 if (table[i] instanceof Entry) { > 1162 int listSize = 0; > 1163 Entry e = (Entry) table[i]; > 1164 for (; e != null; e = (Entry)e.next) { > 1165 Object k; > 1166 if (e.hash == hash && ((k = e.key) == key || key.equals(k))) { > 1167 e.value = value; > 1168 return; > 1169 } > 1170 listSize++; > 1171 } > 1172 // Didn't find, fall through to createEntry(). > 1173 // Check for conversion to TreeBin done via createEntry(). > 1174 checkIfNeedTree = listSize >= TreeBin.TREE_THRESHOLD; > 1175 } else if (table[i] != null) { > ... > 1186 > 1187 createEntry(hash, key, value, i, checkIfNeedTree); > 1188 } > > So the call to createEntry is just recalculating the same "listSize" value: > > 2232 void createEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { > > ... > 2239 if (checkIfNeedTree) { > 2240 int listSize = 0; > 2241 for (e = (Entry) table[bucketIndex]; e != null; e = (Entry)e.next) { > 2242 listSize++; > 2243 if (listSize >= TreeBin.TREE_THRESHOLD) { // Convert to TreeBin > 2244 if (comparableClassFor(key) != null) { > 2245 TreeBin t = new TreeBin(); > 2246 t.populate((Entry)table[bucketIndex]); > 2247 table[bucketIndex] = t; > 2248 } > 2249 break; > 2250 } > 2251 } > 2252 } > Paul. > >> Thanks, >> -Brent >> >> On 6/3/13 12:56 AM, Paul Sandoz wrote: >>> Hi Brent, >>> >>> A minor thing: take it or leave it :-) >>> >>> In HashMap: >>> >>> 2207 void addEntry(int hash, K key, V value, int bucketIndex, boolean checkIfNeedTree) { >>> 2208 // assert key != null; >>> 2209 if ((size >= threshold) && (null != table[bucketIndex])) { >>> 2210 resize(2 * table.length); >>> 2211 hash = hash(key); >>> 2212 bucketIndex = indexFor(hash, table.length); >>> 2213 } >>> 2214 createEntry(hash, key, value, bucketIndex, checkIfNeedTree); >>> 2215 } >>> >>> You could re-verify the bucket size if the table is resized rather >> than in createEntry, since that AFAICT is the only case where conditions >> after the call to addEntry might change. >>> >>> Pau. >>> > From aleksey.shipilev at oracle.com Tue Jun 4 08:36:31 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 04 Jun 2013 12:36:31 +0400 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: References: Message-ID: <51ADA70F.7040208@oracle.com> On 06/04/2013 04:27 AM, Brian Burkhalter wrote: > A) Is there some particular approach that should be used in testing > these algorithms for relative performance? The number one approach is peer review. Is there the JMH project with microbenchmarks somewhere? Sergey (cc'ed) knows a lot about BigInteger/BigDecimal performance, and particular quirks you might be seeing. > B) Could there be something platform-dependent happening? It does not seem likely for pure Java BI/BD benchmarks. Thread scheduling might affect the results; but this seems to be non-essential for single-threaded benchmarks. > C) As currently implemented, the relative performance between > algorithms should be unaffected by thread count, correct? Nope, that is generally incorrect: a) allocation patterns are different; you can hit the allocation wall with multiple threads (which is realistic for highly-loaded systems); the algorithm allocating more temporal objects may be faster in single thread, but slower in multiple threads b) the cache contention effects might be more pronunciated with more threads hitting the same caches c) CMT-enabled machines will have significantly different performance with thread count exceeding the number of cores; d) thread schedulers are known to cause weird decisions for the thread layout when there is the liberty of distributing N threads over M hardware threads (N < M) -Aleksey. From paul.sandoz at oracle.com Tue Jun 4 08:36:56 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Jun 2013 10:36:56 +0200 Subject: RFR: 8015522 - CharSequence.codePoints can be faster In-Reply-To: <51ACFD7D.6020208@oracle.com> References: <51ACFD7D.6020208@oracle.com> Message-ID: <0780B0DD-071E-42FE-900D-8C2F3A7BF899@oracle.com> On Jun 3, 2013, at 10:33 PM, Henry Jen wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~henryjen/tl/8015522.0/webrev/ > > This webrev is based on previous suggestion from Martin Buchholz while > keep the lazy-binding nature without seize the length at construction time. > > The benchmark shows ~50% performance increase, mainly from reduce of > operation, for example, inline block.accept instead of store the > character to a local var also helps. > Looks good. Paul. From ali.ebrahimi1781 at gmail.com Tue Jun 4 09:14:41 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 4 Jun 2013 13:44:41 +0430 Subject: Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll() Message-ID: when building openjfx8 with jdk8b92 i encountered this error : Total time: 5.313 secs :buildSrc:clean :buildSrc:generateGrammarSource error(10): internal error: Can't get property indirectDelegates using method ge t/isIndirectDelegates from org.antlr.tool.Grammar instance : java.lang.NullPointerException java.util.Objects.requireNonNull(Objects.java:203) java.util.ArrayList.removeAll(ArrayList.java:674) org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222) org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav a:43) java.lang.reflect.Method.invoke(Method.java:491) org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563) org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514) org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416) org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java :351) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136) org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEval uator.java:216) org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84 ) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86 ) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86 ) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722) org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659) org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86 ) org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148) org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700) org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278) org.antlr.codegen.Target.genRecognizerFile(Target.java:94) org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463) org.antlr.Tool.generateRecognizer(Tool.java:607) org.antlr.Tool.process(Tool.java:429) org.antlr.Tool.main(Tool.java:91) :buildSrc:generateGrammarSource FAILED the cause of this error is this new changeset: 4802647: Throw required NPEs from removeAll()/retainAll() current code assume that collection.removeAll(null) doesn't do anything. but with this changeset produces NullPointerException that doesn't handled. following is part of source code org/antlr/tool/CompositeGrammar.java (see******** ) 217 /** Get delegates below direct delegates of g */ 218 public List getIndirectDelegates(Grammar g) { 219 List direct = getDirectDelegates(g); 220 List delegates = getDelegates(g); 221 delegates.removeAll(direct);******** 222 return delegates; 223 } 224 225 /** Return list of delegate grammars from root down to g. 226 * Order is root, ..., g.parent. (g not included). 227 */ 228 public List getDelegators(Grammar g) { 229 if ( g==delegateGrammarTreeRoot.grammar ) { 230 return null;********** 231 } 232 List grammars = new ArrayList(); 233 CompositeGrammarTree t = delegateGrammarTreeRoot.findNode(g); 234 // walk backwards to root, collecting grammars 235 CompositeGrammarTree p = t.parent; 236 while ( p!=null ) { 237 grammars.add(0, p.grammar); // add to head so in order later 238 p = p.parent; 239 } 240 return grammars; 241 } So this changeset at least breaks 'antlr' third-party library and any apps depends on. From alan.bateman at oracle.com Tue Jun 4 09:12:54 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 04 Jun 2013 09:12:54 +0000 Subject: hg: jdk8/tl/jdk: 8005698: Handle Frequent HashMap Collisions with Balanced Trees Message-ID: <20130604091322.8CA5748F1D@hg.openjdk.java.net> Changeset: 5223d3228658 Author: bchristi Date: 2013-06-04 10:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5223d3228658 8005698: Handle Frequent HashMap Collisions with Balanced Trees Summary: HashMap bins with many collisions store entries in balanced trees Reviewed-by: alanb, dl, mduigou ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/sun/misc/Hashing.java + test/java/util/Map/CheckRandomHashSeed.java ! test/java/util/Map/Collisions.java + test/java/util/Map/InPlaceOpsCollisions.java + test/java/util/Map/TreeBinSplitBackToEntries.java + test/java/util/Spliterator/SpliteratorCollisions.java From Alan.Bateman at oracle.com Tue Jun 4 09:19:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 10:19:04 +0100 Subject: RFR: 8015522 - CharSequence.codePoints can be faster In-Reply-To: <51ACFD7D.6020208@oracle.com> References: <51ACFD7D.6020208@oracle.com> Message-ID: <51ADB108.7080800@oracle.com> On 03/06/2013 21:33, Henry Jen wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~henryjen/tl/8015522.0/webrev/ > > This webrev is based on previous suggestion from Martin Buchholz while > keep the lazy-binding nature without seize the length at construction time. > > The benchmark shows ~50% performance increase, mainly from reduce of > operation, for example, inline block.accept instead of store the > character to a local var also helps. > > Cheers, > Henry Looks good to me too. -Alan. From Alan.Bateman at oracle.com Tue Jun 4 09:38:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 10:38:50 +0100 Subject: Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll() In-Reply-To: References: Message-ID: <51ADB5AA.40804@oracle.com> On 04/06/2013 10:14, Ali Ebrahimi wrote: > : > > > the cause of this error is this new changeset: > > 4802647: Throw required NPEs from removeAll()/retainAll() > > current code assume that collection.removeAll(null) doesn't do anything. > but with this changeset produces NullPointerException that doesn't handled. > > following is part of source code org/antlr/tool/CompositeGrammar.java > (see******** > ) > > 217 /** Get delegates below direct delegates of g */ > 218 public List getIndirectDelegates(Grammar g) { > 219 List direct = getDirectDelegates(g); > 220 List delegates = getDelegates(g); 221 > delegates.removeAll(direct);******** > 222 return delegates; > 223 } > 224 > 225 /** Return list of delegate grammars from root down to g. > 226 * Order is root, ..., g.parent. (g not included). > 227 */ > 228 public List getDelegators(Grammar g) { > 229 if ( g==delegateGrammarTreeRoot.grammar ) { > 230 return null;********** 231 } > 232 List grammars = new ArrayList(); > 233 CompositeGrammarTree t = delegateGrammarTreeRoot.findNode(g); > 234 // walk backwards to root, collecting grammars > 235 CompositeGrammarTree p = t.parent; > 236 while ( p!=null ) { > 237 grammars.add(0, p.grammar); // add to head so in order later > 238 p = p.parent; > 239 } > 240 return grammars; 241 } > > > So this changeset at least breaks 'antlr' third-party library and any apps > depends on. Thanks for the bug report. It does seem to have exposed a bug in antlr. Kevin Rushforth (FX) and Mike Duigou have been looking into the same thing via 8015656. -Alan. From paul.sandoz at oracle.com Tue Jun 4 09:55:01 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 04 Jun 2013 09:55:01 +0000 Subject: hg: jdk8/tl/jdk: 8015790: Remove duplicate spliterator tests Message-ID: <20130604095545.4BD1148F1F@hg.openjdk.java.net> Changeset: fad4ef2123ca Author: psandoz Date: 2013-06-04 11:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad4ef2123ca 8015790: Remove duplicate spliterator tests Reviewed-by: alanb, mduigou - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java From michael.x.mcmahon at oracle.com Tue Jun 4 09:57:58 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 04 Jun 2013 09:57:58 +0000 Subject: hg: jdk8/tl/jdk: 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing Message-ID: <20130604095818.9D81848F20@hg.openjdk.java.net> Changeset: f8b071428ca5 Author: michaelm Date: 2013-06-04 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b071428ca5 8014723: sun/misc/URLClassPath/ClassnameCharTest.java failing Reviewed-by: alanb, chegar ! src/share/classes/java/net/HttpURLPermission.java ! test/ProblemList.txt From ali.ebrahimi1781 at gmail.com Tue Jun 4 10:08:11 2013 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 4 Jun 2013 14:38:11 +0430 Subject: Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll() In-Reply-To: <51ADB5AA.40804@oracle.com> References: <51ADB5AA.40804@oracle.com> Message-ID: What we this: previous result: before changeset collection.removeAll(null) do nothing if collection is empty collection.removeAll(null) NullPointerException if collection is not empty current result: after changeset collection.removeAll(null) NullPointerException if collection is empty collection.removeAll(null) NullPointerException if collection is not empty solutions: solution1: backout/revert changeset solution2: patch changeset public boolean removeAll(Collection c) { if(!isEmpty()) Objects.requireNonNull(c); boolean modified = false; Iterator it = iterator(); while (it.hasNext()) { if (c.contains(it.next())) { it.remove(); modified = true; } } return modified; } public boolean retainAll(Collection c) { if(!isEmpty()) Objects.requireNonNull(c); boolean modified = false; Iterator it = iterator(); while (it.hasNext()) { if (!c.contains(it.next())) { it.remove(); modified = true; } } return modified; } this is behaviorally compatible change. On Tue, Jun 4, 2013 at 2:08 PM, Alan Bateman wrote: > On 04/06/2013 10:14, Ali Ebrahimi wrote: > >> : >> >> >> the cause of this error is this new changeset: >> >> 4802647: Throw required NPEs from removeAll()/retainAll() >> >> current code assume that collection.removeAll(null) doesn't do anything. >> but with this changeset produces NullPointerException that doesn't >> handled. >> >> following is part of source code org/antlr/tool/**CompositeGrammar.java >> (see******** >> ) >> >> 217 /** Get delegates below direct delegates of g */ >> 218 public List getIndirectDelegates(Grammar g) { >> 219 List direct = getDirectDelegates(g); >> 220 List delegates = getDelegates(g); 221 >> delegates.removeAll(direct);********** >> 222 return delegates; >> 223 } >> 224 >> 225 /** Return list of delegate grammars from root down to g. >> 226 * Order is root, ..., g.parent. (g not included). >> 227 */ >> 228 public List getDelegators(Grammar g) { >> 229 if ( g==delegateGrammarTreeRoot.**grammar ) { >> 230 return null;********** 231 } >> 232 List grammars = new ArrayList(); >> 233 CompositeGrammarTree t = delegateGrammarTreeRoot. >> **findNode(g); >> 234 // walk backwards to root, collecting grammars >> 235 CompositeGrammarTree p = t.parent; >> 236 while ( p!=null ) { >> 237 grammars.add(0, p.grammar); // add to >> head so in order later >> 238 p = p.parent; >> 239 } >> 240 return grammars; 241 } >> >> >> So this changeset at least breaks 'antlr' third-party library and any apps >> depends on. >> > Thanks for the bug report. It does seem to have exposed a bug in antlr. > Kevin Rushforth (FX) and Mike Duigou have been looking into the same thing > via 8015656. > > -Alan. > > From Alan.Bateman at oracle.com Tue Jun 4 10:33:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 11:33:39 +0100 Subject: 8015872: ProblemList.txt updates (6/2013) Message-ID: <51ADC283.7080604@oracle.com> I need a reviewer to update jdk/test/ProblemList.txt again. Bugs are submitted for each of the issues. -Alan. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -134,6 +134,9 @@ # 8008200 java/lang/Class/asSubclass/BasicUnit.java generic-all +# 8015780 +java/lang/reflect/Method/GenericStringTest.java generic-all + ############################################################################ # jdk_management @@ -274,6 +277,13 @@ sun/security/pkcs11/ec/ReadPKCS12.java solaris-all sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java solaris-all +# 8005247 +sun/security/pkcs11/ec/TestECDSA.java solaris-all + +# 8009438 +sun/security/pkcs11/Secmod/AddPrivateKey.java linux-all +sun/security/pkcs11/Secmod/TrustAnchors.java linux-all + # 7041639, Solaris DSA keypair generation bug (Note: jdk_util also affected) java/security/KeyPairGenerator/SolarisShortDSA.java solaris-all sun/security/tools/jarsigner/onlymanifest.sh solaris-all From sergey.kuksenko at oracle.com Tue Jun 4 10:41:54 2013 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Tue, 04 Jun 2013 14:41:54 +0400 Subject: RFR: 8015522 - CharSequence.codePoints can be faster In-Reply-To: <51ACFD7D.6020208@oracle.com> References: <51ACFD7D.6020208@oracle.com> Message-ID: <51ADC472.7070807@oracle.com> Hi JavaDoc to the method says: "If the sequence is mutated while the stream is being read, the result is undefined." What about exceptions? If the sequence is mutated and length becomes smaller you'll get IndexOutOfBoundsException in forEachRemaining method. On 06/04/2013 12:33 AM, Henry Jen wrote: > Hi, > > Please review > http://cr.openjdk.java.net/~henryjen/tl/8015522.0/webrev/ > > This webrev is based on previous suggestion from Martin Buchholz while > keep the lazy-binding nature without seize the length at construction time. > > The benchmark shows ~50% performance increase, mainly from reduce of > operation, for example, inline block.accept instead of store the > character to a local var also helps. > > Cheers, > Henry > -- Best regards, Sergey Kuksenko From maurizio.cimadamore at oracle.com Tue Jun 4 10:45:28 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 04 Jun 2013 10:45:28 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130604104540.031B548F23@hg.openjdk.java.net> Changeset: 5cd3cb69c8b3 Author: mcimadamore Date: 2013-06-04 11:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5cd3cb69c8b3 7116676: RichDiagnosticFormatter throws NPE when formatMessage is called directly Summary: Fix NPE in RichDiagnosticFormatter.formatMessage Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/Diagnostics/7116676/T7116676.java Changeset: 32c50b5f70b5 Author: mcimadamore Date: 2013-06-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32c50b5f70b5 8008160: Five lambda TargetType tests have @ignore Summary: Remove @ignore flags from tests that now pass Reviewed-by: jjg ! test/tools/javac/lambda/TargetType53.java ! test/tools/javac/lambda/TargetType54.java ! test/tools/javac/lambda/TargetType58.java ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java Changeset: c8acc254b6d7 Author: mcimadamore Date: 2013-06-04 11:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c8acc254b6d7 8015505: Spurious inference error when return type of generic method requires unchecked conversion to target Summary: Use check context compatibility during 15.12.2.8 check (only when JDK 8 inference is enabled) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8015505/T8015505.java + test/tools/javac/generics/inference/8015505/T8015505.out ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java From chris.hegarty at oracle.com Tue Jun 4 10:51:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Jun 2013 11:51:38 +0100 Subject: 8015872: ProblemList.txt updates (6/2013) In-Reply-To: <51ADC283.7080604@oracle.com> References: <51ADC283.7080604@oracle.com> Message-ID: <51ADC6BA.6090005@oracle.com> Looks fine to me Alan. This should hopefully make test runs quieter, until the issues can be addressed. -Chris. On 06/04/2013 11:33 AM, Alan Bateman wrote: > > I need a reviewer to update jdk/test/ProblemList.txt again. Bugs are > submitted for each of the issues. > > -Alan. > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -134,6 +134,9 @@ > # 8008200 > java/lang/Class/asSubclass/BasicUnit.java generic-all > > +# 8015780 > +java/lang/reflect/Method/GenericStringTest.java generic-all > + > ############################################################################ > > # jdk_management > @@ -274,6 +277,13 @@ > sun/security/pkcs11/ec/ReadPKCS12.java solaris-all > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java solaris-all > > +# 8005247 > +sun/security/pkcs11/ec/TestECDSA.java solaris-all > + > +# 8009438 > +sun/security/pkcs11/Secmod/AddPrivateKey.java linux-all > +sun/security/pkcs11/Secmod/TrustAnchors.java linux-all > + > # 7041639, Solaris DSA keypair generation bug (Note: jdk_util also > affected) > java/security/KeyPairGenerator/SolarisShortDSA.java solaris-all > sun/security/tools/jarsigner/onlymanifest.sh solaris-all From alan.bateman at oracle.com Tue Jun 4 10:54:03 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 04 Jun 2013 10:54:03 +0000 Subject: hg: jdk8/tl/jdk: 8015872: ProblemList.txt updates (6/2013) Message-ID: <20130604105418.1BA0F48F24@hg.openjdk.java.net> Changeset: 780fbbd50ce4 Author: alanb Date: 2013-06-04 11:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/780fbbd50ce4 8015872: ProblemList.txt updates (6/2013) Reviewed-by: chegar ! test/ProblemList.txt From vicente.romero at oracle.com Tue Jun 4 12:22:08 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 04 Jun 2013 12:22:08 +0000 Subject: hg: jdk8/tl/langtools: 7165659: javac incorrectly sets strictfp access flag on inner-classes Message-ID: <20130604122211.584C048F28@hg.openjdk.java.net> Changeset: 775a51e3276f Author: vromero Date: 2013-06-04 13:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/775a51e3276f 7165659: javac incorrectly sets strictfp access flag on inner-classes Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/T7165659/InnerClassAttrMustNotHaveStrictFPFlagTest.java From Alan.Bateman at oracle.com Tue Jun 4 12:45:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 13:45:12 +0100 Subject: RFR: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted In-Reply-To: <51ACA34B.7090506@oracle.com> References: <51ACA34B.7090506@oracle.com> Message-ID: <51ADE158.6050304@oracle.com> On 03/06/2013 15:08, Coleen Phillimore wrote: > Summary: The code for this test is fixed now and integrated to TL repo > and it passes now. > > open webrev at http://cr.openjdk.java.net/~coleenp/7124706_jdk/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7124706_jdk > > Thanks, > Coleen Looks fine to me. Also apologies about MakeJAR4.sh, it looks like I missed the $ when updating the tests to support $COMPILEJAVA. -Alan From jason_mehrens at hotmail.com Tue Jun 4 13:44:57 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 4 Jun 2013 08:44:57 -0500 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51ACA5AB.5050606@oracle.com> References: <5177E3C4.3090703@oracle.com>, <517821CB.70608@oracle.com>, ,,<517E7982.8060803@oracle.com>, <517F6DDB.4020809@oracle.com>, ,,<518E9F55.6030603@oracle.com>, <5196864B.1040003@oracle.com>, ,,, , , <519B5444.7060701@oracle.com>, , , , <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>,,<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>, , <51A49D6B.3020407@oracle.com>, , , <51A55C70.4070403@oracle.com>, , <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>,<51ACA5AB.5050606@oracle.com> Message-ID: Aleksej, Looks good to me. I think Alan wanted you to use the ser files to create a byte array + ByteArrayInputStream in the actual test class instead of including actual serial data files along side the test. Jason > The next version of webrev: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.4/ > > The list of changes: > 1. The test was moved to jdk/test/javax/xml/jaxp/XPath/8009579 > 2. Throw of InvalidClassException was added > 3. Two test cases were added: > a) Deserialization of XPathException initialized by ordinary values > and serialized by JDK7 build (normal_jdk7.ser file) > b) Deserialization of "new XPathException(new > Exception()).initCause(null)" XPathException serialized by JDK7 build > (twocauses_jdk7.ser file). > > -Aleksej [snip] > > > I see you've added a serialization/deserialization test (thanks) but > > it wouldn't have caught this. What would you think about serializing a > > few XPathException instances with a jdk7 build and use the byte stream > > in the test to check that they are handled correctly. That would give > > more confident that there aren't any other holes. > > > > -Alan > From sergey.kuksenko at oracle.com Tue Jun 4 13:49:02 2013 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Tue, 04 Jun 2013 17:49:02 +0400 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <51ADA70F.7040208@oracle.com> References: <51ADA70F.7040208@oracle.com> Message-ID: <51ADF04E.7060605@oracle.com> Brian, could you show your benchmark? My quick experiments show that current Karatsuba threshold is quite reasonable. On 06/04/2013 12:36 PM, Aleksey Shipilev wrote: > On 06/04/2013 04:27 AM, Brian Burkhalter wrote: >> A) Is there some particular approach that should be used in testing >> these algorithms for relative performance? > > The number one approach is peer review. Is there the JMH project with > microbenchmarks somewhere? Sergey (cc'ed) knows a lot about > BigInteger/BigDecimal performance, and particular quirks you might be > seeing. > >> B) Could there be something platform-dependent happening? > > It does not seem likely for pure Java BI/BD benchmarks. Thread > scheduling might affect the results; but this seems to be non-essential > for single-threaded benchmarks. > >> C) As currently implemented, the relative performance between >> algorithms should be unaffected by thread count, correct? > > Nope, that is generally incorrect: > a) allocation patterns are different; you can hit the allocation wall > with multiple threads (which is realistic for highly-loaded systems); > the algorithm allocating more temporal objects may be faster in single > thread, but slower in multiple threads > b) the cache contention effects might be more pronunciated with more > threads hitting the same caches > c) CMT-enabled machines will have significantly different performance > with thread count exceeding the number of cores; > d) thread schedulers are known to cause weird decisions for the thread > layout when there is the liberty of distributing N threads over M > hardware threads (N < M) > > > -Aleksey. > -- Best regards, Sergey Kuksenko From coleen.phillimore at oracle.com Tue Jun 4 13:46:07 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Jun 2013 09:46:07 -0400 Subject: RFR: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted In-Reply-To: <51ADE158.6050304@oracle.com> References: <51ACA34B.7090506@oracle.com> <51ADE158.6050304@oracle.com> Message-ID: <51ADEF9F.9020808@oracle.com> On 06/04/2013 08:45 AM, Alan Bateman wrote: > On 03/06/2013 15:08, Coleen Phillimore wrote: >> Summary: The code for this test is fixed now and integrated to TL >> repo and it passes now. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7124706_jdk/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7124706_jdk >> >> Thanks, >> Coleen > Looks fine to me. > > Also apologies about MakeJAR4.sh, it looks like I missed the $ when > updating the tests to support $COMPILEJAVA. N.P. Thanks! I'll do a JPRT test job for it before checking it in. Coleen > > -Alan From Alan.Bateman at oracle.com Tue Jun 4 13:57:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Jun 2013 06:57:42 -0700 (PDT) Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> Message-ID: <51ADF256.2090303@oracle.com> On 04/06/2013 14:44, Jason Mehrens wrote: > Aleksej, > > Looks good to me. I think Alan wanted you to use the ser files to create a byte array + ByteArrayInputStream in the actual test class instead of including actual serial data files along side the test. > That would be my preference because we try to avoid binary files in the repository. -Alan. From Alan.Bateman at oracle.com Tue Jun 4 14:25:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jun 2013 15:25:29 +0100 Subject: RFR: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported In-Reply-To: <519F72DE.80805@oracle.com> References: <519F253E.3070003@oracle.com> <519F72DE.80805@oracle.com> Message-ID: <51ADF8D9.4050504@oracle.com> On 24/05/2013 15:02, Alan Bateman wrote: > On 24/05/2013 09:30, Henry Jen wrote: >> Hi, >> >> Please review a fix for 8014855. >> >> http://cr.openjdk.java.net/~henryjen/tl/8014855.0/webrev/ >> >> The fix ensure we only test symbolic link related scenario on systems >> support it. >> > Thanks for taking one. > > One idea is to just create empty files when sym links are supported. > That way only the test for Files.walk following sym links needs to be > skipped when sym links aren't supported. Looking at this again, what you have is fine. I can sponsor this and get it into jdk8/tl today. -Alan. From alan.bateman at oracle.com Tue Jun 4 14:26:42 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 04 Jun 2013 14:26:42 +0000 Subject: hg: jdk8/tl/jdk: 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported Message-ID: <20130604142715.C1D5E48F2A@hg.openjdk.java.net> Changeset: 25a8e6fd0210 Author: alanb Date: 2013-06-04 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25a8e6fd0210 8014855: TEST_BUG: java/nio/file/Files/StreamTest.java fails when sym links not supported Reviewed-by: alanb Contributed-by: henry.jen at oracle.com ! test/java/nio/file/Files/StreamTest.java From nm3mon at gmail.com Tue Jun 4 14:55:50 2013 From: nm3mon at gmail.com (Nabeel Memon) Date: Tue, 4 Jun 2013 10:55:50 -0400 Subject: Fwd: Prohibited package name: java.util.stream In-Reply-To: <51AD8148.8080102@oracle.com> References: <51AD8148.8080102@oracle.com> Message-ID: Thanks a lot Mike, Jon and Alan. Although building from source wasn't as straight-forward as I mentioned but I got it running. Someone should add these details to the document to make it easier for others. Nabeel On Tue, Jun 4, 2013 at 1:55 AM, Alan Bateman wrote: > On 03/06/2013 21:00, Nabeel Memon wrote: > >> Simply running 'make jdk_util' under the test folder is failing and >> throwing the same exception: >> >> java.lang.SecurityException: Prohibited package name: java.util.stream... >> >> for all test sources under under: >> >> java/util/stream/test/* and java/util/stream/boottest/* >> >> >> Can anyone please verify if i've missed something or this is a known >> issue? >> >> >> >> Nabeel >> > The stream tests add classes on the boot class path and need the latest > jtreg to get that support. This means building jtreg yourself and I see > you've started a discussion on jtreg-use about that. > > -Alan > From kevin.rushforth at oracle.com Tue Jun 4 15:10:41 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Jun 2013 08:10:41 -0700 Subject: Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll() In-Reply-To: <51ADB5AA.40804@oracle.com> References: <51ADB5AA.40804@oracle.com> Message-ID: <51AE0371.9050001@oracle.com> Currently our workaround for the FX gradle build is to run the antlr task using an earlier JDK (b90) and the rest with b91 or later. We haven't looked for another workaround yet. -- Kevin Alan Bateman wrote: > On 04/06/2013 10:14, Ali Ebrahimi wrote: >> : >> >> >> the cause of this error is this new changeset: >> >> 4802647: Throw required NPEs from removeAll()/retainAll() >> >> current code assume that collection.removeAll(null) doesn't do anything. >> but with this changeset produces NullPointerException that doesn't >> handled. >> >> following is part of source code org/antlr/tool/CompositeGrammar.java >> (see******** >> ) >> >> 217 /** Get delegates below direct delegates of g */ >> 218 public List getIndirectDelegates(Grammar g) { >> 219 List direct = getDirectDelegates(g); >> 220 List delegates = getDelegates(g); 221 >> delegates.removeAll(direct);******** >> 222 return delegates; >> 223 } >> 224 >> 225 /** Return list of delegate grammars from root down to g. >> 226 * Order is root, ..., g.parent. (g not included). >> 227 */ >> 228 public List getDelegators(Grammar g) { >> 229 if ( g==delegateGrammarTreeRoot.grammar ) { >> 230 return null;********** 231 } >> 232 List grammars = new ArrayList(); >> 233 CompositeGrammarTree t = >> delegateGrammarTreeRoot.findNode(g); >> 234 // walk backwards to root, collecting grammars >> 235 CompositeGrammarTree p = t.parent; >> 236 while ( p!=null ) { >> 237 grammars.add(0, p.grammar); // add to head so in >> order later >> 238 p = p.parent; >> 239 } >> 240 return grammars; 241 } >> >> >> So this changeset at least breaks 'antlr' third-party library and any >> apps >> depends on. > Thanks for the bug report. It does seem to have exposed a bug in > antlr. Kevin Rushforth (FX) and Mike Duigou have been looking into the > same thing via 8015656. > > -Alan. > From aleksej.efimov at oracle.com Tue Jun 4 15:19:30 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 04 Jun 2013 19:19:30 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51ADF256.2090303@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> Message-ID: <51AE0582.7030909@oracle.com> Alan, Jason, Thanks for clarification. I have moved the serial data from binary files to test class: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ -Aleksej On 06/04/2013 05:57 PM, Alan Bateman wrote: > On 04/06/2013 14:44, Jason Mehrens wrote: >> Aleksej, >> >> Looks good to me. I think Alan wanted you to use the ser files to >> create a byte array + ByteArrayInputStream in the actual test class >> instead of including actual serial data files along side the test. >> > That would be my preference because we try to avoid binary files in > the repository. > > -Alan. > > From huizhe.wang at oracle.com Tue Jun 4 16:36:06 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 04 Jun 2013 16:36:06 +0000 Subject: hg: jdk8/tl/jaxp: 8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 Message-ID: <20130604163612.CDF1648F30@hg.openjdk.java.net> Changeset: 5b958f0a5498 Author: joehw Date: 2013-06-04 09:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5b958f0a5498 8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 Reviewed-by: alanb ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java From huizhe.wang at oracle.com Tue Jun 4 16:45:51 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 04 Jun 2013 09:45:51 -0700 Subject: RFR (jaxp): JDK-8015630: Remove default restriction settings of jaxp 1.5 properties in JDK8 In-Reply-To: <51AD8F28.80808@oracle.com> References: <51AD7712.800@oracle.com> <51AD8F28.80808@oracle.com> Message-ID: <51AE19BF.4040708@oracle.com> Done. Thanks! Joe On 6/3/2013 11:54 PM, Alan Bateman wrote: > On 04/06/2013 06:11, huizhe wang wrote: >> Hi, >> >> The default restriction in JDK8 is too strict. We've heard enough of >> complaints and decided to remove it. Below is the quick fix to remove >> the default restriction setting. >> >> Also, there was a bug in XMLSchemaFactory's setFeature method where >> the access properties should be set only when secure processing is true. >> >> webrevs: >> http://cr.openjdk.java.net/~joehw/jdk8/8015630/webrev/ >> >> Tests pass after removing restriction check. > This seems the most sensible thing to do and the changes look okay to me. > > -Alan. > From naoto.sato at oracle.com Tue Jun 4 17:34:18 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 04 Jun 2013 17:34:18 +0000 Subject: hg: jdk8/tl/jdk: 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows Message-ID: <20130604173453.3630C48F3B@hg.openjdk.java.net> Changeset: 379e1bcae693 Author: naoto Date: 2013-06-04 10:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/379e1bcae693 8013903: Japanese calendar field names are not displayed with -Djava.locale.providers=HOST on Windows Reviewed-by: okutsu ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From brian.burkhalter at oracle.com Tue Jun 4 17:44:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Jun 2013 10:44:39 -0700 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <51ADF04E.7060605@oracle.com> References: <51ADA70F.7040208@oracle.com> <51ADF04E.7060605@oracle.com> Message-ID: Hi Sergey, On Jun 4, 2013, at 6:49 AM, Sergey Kuksenko wrote: > could you show your benchmark? Please see code below. > My quick experiments show that current Karatsuba threshold is quite reasonable. I hope that you are correct. I would like to know why I am seeing such different numbers. Thanks, Brian /** * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it under * the terms of the GNU General Public License version 2 only, as published by * the Free Software Foundation. Oracle designates this particular file as * subject to the "Classpath" exception as provided by Oracle in the LICENSE * file that accompanied this code. * * This code is distributed in the hope that it will be useful, but WITHOUT ANY * WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR * A PARTICULAR PURPOSE. See the GNU General Public License version 2 for more * details (a copy is included in the LICENSE file that accompanied this code). * * You should have received a copy of the GNU General Public License version 2 * along with this work; if not, write to the Free Software Foundation, Inc., 51 * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA or * visit www.oracle.com if you need additional information or have any * questions. */ package corelibs; import java.math.BigInteger; import java.util.Random; import java.util.concurrent.TimeUnit; import org.openjdk.jmh.annotations.BenchmarkType; import org.openjdk.jmh.annotations.GenerateMicroBenchmark; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.State; public class BigIntegerBench { static final int BITS_KARATSUBA = 1600; static final int BITS_TOOM_COOK = 2400; static final int BITS_KARATSUBA_SQUARE = 2880; static final int BITS_TOOM_COOK_SQUARE = 4480; static final int BITS_GENERIC = 1600; @State(Scope.Benchmark) public static class BenchmarkState { Random random = new Random(42L); BigInteger genericFactor1 = new BigInteger(BITS_GENERIC + 1, random); BigInteger genericFactor2 = new BigInteger(BITS_GENERIC + 400, random); @OutputTimeUnit(TimeUnit.MICROSECONDS) @GenerateMicroBenchmark(BenchmarkType.AverageTimePerOp) public BigInteger multiplyStandardGeneric(BenchmarkState state) { return state.genericFactor1.multiply_standard(state.genericFactor2); } @OutputTimeUnit(TimeUnit.MICROSECONDS) @GenerateMicroBenchmark(BenchmarkType.AverageTimePerOp) public BigInteger multiplyKaratsubaGeneric(BenchmarkState state) { return state.genericFactor1.multiply_karatsuba(state.genericFactor2); } @OutputTimeUnit(TimeUnit.MICROSECONDS) @GenerateMicroBenchmark(BenchmarkType.AverageTimePerOp) public BigInteger multiplyToomCookGeneric(BenchmarkState state) { return state.genericFactor1.multiply_toom_cook(state.genericFactor2); } } From brian.burkhalter at oracle.com Tue Jun 4 17:47:44 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Jun 2013 10:47:44 -0700 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <51ADA70F.7040208@oracle.com> References: <51ADA70F.7040208@oracle.com> Message-ID: <28362C69-4777-4CF7-A000-F1AE0B11F126@oracle.com> Hi Aleksey, On Jun 4, 2013, at 1:36 AM, Aleksey Shipilev wrote: > On 06/04/2013 04:27 AM, Brian Burkhalter wrote: >> A) Is there some particular approach that should be used in testing >> these algorithms for relative performance? > > The number one approach is peer review. Is there the JMH project with > microbenchmarks somewhere? Sergey (cc'ed) knows a lot about > BigInteger/BigDecimal performance, and particular quirks you might be > seeing. Abbreviated code posted to this forum. >> B) Could there be something platform-dependent happening? > > It does not seem likely for pure Java BI/BD benchmarks. Thread > scheduling might affect the results; but this seems to be non-essential > for single-threaded benchmarks. Thanks for confirming this. >> C) As currently implemented, the relative performance between >> algorithms should be unaffected by thread count, correct? > > Nope, that is generally incorrect: > a) allocation patterns are different; you can hit the allocation wall > with multiple threads (which is realistic for highly-loaded systems); > the algorithm allocating more temporal objects may be faster in single > thread, but slower in multiple threads > b) the cache contention effects might be more pronunciated with more > threads hitting the same caches > c) CMT-enabled machines will have significantly different performance > with thread count exceeding the number of cores; > d) thread schedulers are known to cause weird decisions for the thread > layout when there is the liberty of distributing N threads over M > hardware threads (N < M) I should have been clear that I never used more threads than the number of cores, viz., two. Thanks, Brian From jonathan.gibbons at oracle.com Tue Jun 4 21:19:14 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 04 Jun 2013 21:19:14 +0000 Subject: hg: jdk8/tl/langtools: 8004643: Reduce javac space overhead introduced with compiler support for repeating annotations Message-ID: <20130604211917.77FDE48F4C@hg.openjdk.java.net> Changeset: 8fb68f73d4b1 Author: jjg Date: 2013-06-04 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8fb68f73d4b1 8004643: Reduce javac space overhead introduced with compiler support for repeating annotations Reviewed-by: mcimadamore, jfranck ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lib/DPrinter.java From chris.hegarty at oracle.com Tue Jun 4 22:10:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 04 Jun 2013 22:10:55 +0000 Subject: hg: jdk8/tl/jdk: 8005704: Update ConcurrentHashMap to v8 Message-ID: <20130604221108.8CB1B48F4E@hg.openjdk.java.net> Changeset: d6401129327e Author: dl Date: 2013-06-04 21:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6401129327e 8005704: Update ConcurrentHashMap to v8 Reviewed-by: chegar, mduigou ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From mandy.chung at oracle.com Tue Jun 4 22:45:05 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 04 Jun 2013 22:45:05 +0000 Subject: hg: jdk8/tl/jdk: 8014097: add doPrivileged methods with limited privilege scope Message-ID: <20130604224517.2AD3D48F51@hg.openjdk.java.net> Changeset: bd84bad9ee99 Author: jdn Date: 2013-06-04 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd84bad9ee99 8014097: add doPrivileged methods with limited privilege scope Reviewed-by: mchung ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java + test/java/security/AccessController/LimitedDoPrivileged.java From sean.coffey at oracle.com Tue Jun 4 22:57:00 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 04 Jun 2013 23:57:00 +0100 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package Message-ID: <51AE70BC.3050305@oracle.com> The com.sun.corba.se.impl package is a private package. The API is subject to change at any time and no 3rd party code should be using it. As a result, I'd like to add it to the package restricted list. I've run our internal CORBA SQE testsuite against the proposed change and didn't see any issues. bug report : http://bugs.sun.com/view_bug.do?bug_id=8000450 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8/ I plan to port the same change to jdk7u. regards, Sean. From Lance.Andersen at oracle.com Tue Jun 4 23:30:31 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 4 Jun 2013 19:30:31 -0400 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package In-Reply-To: <51AE70BC.3050305@oracle.com> References: <51AE70BC.3050305@oracle.com> Message-ID: the changes make sense to me On Jun 4, 2013, at 6:57 PM, Se?n Coffey wrote: > The com.sun.corba.se.impl package is a private package. The API is subject to change at any time and no 3rd party code should be using it. As a result, I'd like to add it to the package restricted list. I've run our internal CORBA SQE testsuite against the proposed change and didn't see any issues. > > bug report : http://bugs.sun.com/view_bug.do?bug_id=8000450 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8/ > > I plan to port the same change to jdk7u. > > regards, > Sean. -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From youdwei at linux.vnet.ibm.com Wed Jun 5 05:26:16 2013 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Wed, 05 Jun 2013 13:26:16 +0800 Subject: Non Inherited repeated annotations should not be searched from child Class In-Reply-To: <51ADED9C.1050105@linux.vent.ibm.com> References: <51ADED9C.1050105@linux.vent.ibm.com> Message-ID: <51AECBF8.90300@linux.vnet.ibm.com> Hi All, I didn't see this mail in the mailing list for a long time, so I just comment here to ensure everyone can receive this message. Thanks a lot! On 06/04/2013 09:37 PM, Deven You wrote: > > Hi All, > > I have written a test case[1] to show this problem. (If it is > confirmed a real bug, I will convert this test case to jtreg) > > My expected output is no any output but OpenJDK returns: > > @NonInheritedAnnotationRepeated(name=A) > @NonInheritedAnnotationRepeated(name=B) > > The reasons are: > > 1. From the spec, Inherited means: > > Indicates that an annotation type is automatically inherited. If an > Inherited meta-annotation is present on an annotation type > declaration, and the user queries the annotation type on a class > declaration, and the class declaration has no annotation for this > type, then the class's superclass will automatically be queried for > the annotation type. This process will be repeated until an annotation > for this type is found, or the top of the class hierarchy (Object) is > reached. If no superclass has an annotation for this type, then the > query will indicate that the class in question has no such annotation. > > 2. For repeated annotations, according to the explanation of 1., If it > is non-inherited, querying Child class of this annotation should > return null. > > 3. Now the problem is if the repeated annotation is non-inherited, but > its container annotation is inherited, OpenJDK will return the > repeated annotations of Parent class if we query the Child class. > > It seems according to the Inherited semantics, even when container > annotation is inherited, we should not retrieve parent class > non-inherited repeated annotation from a child class. > > [1] http://cr.openjdk.java.net/~youdwei/ojdk-810/NonInheritedTest/ > From Alan.Bateman at oracle.com Wed Jun 5 06:20:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Jun 2013 07:20:08 +0100 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package In-Reply-To: <51AE70BC.3050305@oracle.com> References: <51AE70BC.3050305@oracle.com> Message-ID: <51AED898.9010104@oracle.com> On 04/06/2013 23:57, Se?n Coffey wrote: > The com.sun.corba.se.impl package is a private package. The API is > subject to change at any time and no 3rd party code should be using > it. As a result, I'd like to add it to the package restricted list. > I've run our internal CORBA SQE testsuite against the proposed change > and didn't see any issues. > > bug report : http://bugs.sun.com/view_bug.do?bug_id=8000450 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8/ > > I plan to port the same change to jdk7u. Nobody should be using com.sun.corba.se.impl directly so the change looks good to me. The @summary in the tests suggests it was originally written for JAXP so if the test scope is extended then that summary will need to be updated. I also note that the test only uses checkPackageAccess so I don't think it actually checks entries on the package.definitions list. We should probably write a more complete test, although I'm not suggest you have to do this here. -Alan From lana.steuck at oracle.com Wed Jun 5 06:33:28 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jun 2013 06:33:28 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130605063338.47C7A48F61@hg.openjdk.java.net> Changeset: 4463e94d9b0d Author: lana Date: 2013-05-29 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4463e94d9b0d Merge - src/jdk/nashorn/internal/runtime/options/ValueOption.java - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: ddbf41575a2b Author: lana Date: 2013-06-03 23:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ddbf41575a2b Merge - src/jdk/nashorn/internal/runtime/options/ValueOption.java - src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java - src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java - src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java - src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java - src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java - src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java - src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java - src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java - src/netscape/javascript/JSObject.java Changeset: d2bd881976b5 Author: lana Date: 2013-06-04 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d2bd881976b5 Merge From lana.steuck at oracle.com Wed Jun 5 06:33:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jun 2013 06:33:12 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20130605063313.8166F48F60@hg.openjdk.java.net> Changeset: 78852ce176db Author: jqzuo Date: 2013-05-28 20:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/78852ce176db 8014762: Add JMC configure option mapping to Jprt.gmk Summary: Need to add the mapping between JPRT env var and configure flag for JMC, from ALT_JMC_ZIP_DIR to --with-jmc-zip-dir (same pattern as for Javafx) Reviewed-by: tbell, erikj Contributed-by: klara.ward at oracle.com ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: c22d59e3f06e Author: pbhat Date: 2013-05-29 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c22d59e3f06e Merge Changeset: ea6f3bf82903 Author: jqzuo Date: 2013-06-04 00:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ea6f3bf82903 Merge ! common/autoconf/generated-configure.sh From lana.steuck at oracle.com Wed Jun 5 06:33:17 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jun 2013 06:33:17 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20130605063341.31C9B48F62@hg.openjdk.java.net> Changeset: 627c265d6e0c Author: lana Date: 2013-05-29 16:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/627c265d6e0c Merge - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: d583a491d63c Author: lana Date: 2013-06-03 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d583a491d63c Merge - src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java Changeset: e996ea806630 Author: lana Date: 2013-06-04 21:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e996ea806630 Merge From lana.steuck at oracle.com Wed Jun 5 06:33:31 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jun 2013 06:33:31 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130605063350.E09D548F63@hg.openjdk.java.net> Changeset: 18943a1b7a47 Author: lana Date: 2013-05-29 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/18943a1b7a47 Merge - test/tools/javac/HiddenAbstractMethod/Test - test/tools/javac/NonAmbiguousField/Test Changeset: 2c5a568ee36e Author: lana Date: 2013-06-03 23:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2c5a568ee36e Merge - test/tools/javac/HiddenAbstractMethod/Test - test/tools/javac/NonAmbiguousField/Test Changeset: 9acd0f8d6e44 Author: lana Date: 2013-06-04 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9acd0f8d6e44 Merge From lana.steuck at oracle.com Wed Jun 5 06:37:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jun 2013 06:37:11 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20130605064724.065D748F65@hg.openjdk.java.net> Changeset: 93de1ab38793 Author: jchen Date: 2013-05-17 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93de1ab38793 8003444: Fix potential NULL pointer dereference Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c Changeset: 0cec8dc2bcf8 Author: lana Date: 2013-05-22 19:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cec8dc2bcf8 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 0208f5f12dc3 Author: jchen Date: 2013-05-23 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0208f5f12dc3 8012629: java.lang.UnsatisfiedLinkError exception throw by getAllFonts() on MacOSX Reviewed-by: bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mawt.gmk ! makefiles/CompileNativeLibraries.gmk ! src/macosx/native/sun/font/AWTFont.m Changeset: f24f9038e050 Author: prr Date: 2013-05-24 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f24f9038e050 8008535: JDK7 Printing : CJK and Latin Text in a string overlap Reviewed-by: bae, jgodinez ! src/windows/classes/sun/awt/windows/WPathGraphics.java + test/java/awt/print/PrinterJob/PrintLatinCJKTest.java Changeset: f4ad2fa22474 Author: jgodinez Date: 2013-05-29 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4ad2fa22474 7183520: [macosx]Unable to print out the defined page for 2D_PrintingTiger/JTablePrintPageRangesTest. Reviewed-by: bae, prr ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java Changeset: 7e2a887a069e Author: jgodinez Date: 2013-05-29 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e2a887a069e 8012381: [macosx]Unable to print out the defined page for 2D_PrintingTiger/JTablePrintPageRangesTest Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/IPPPrintService.java ! test/java/awt/print/PrinterJob/Collate2DPrintingTest.java Changeset: 8ac29ee867fd Author: lana Date: 2013-05-29 16:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ac29ee867fd Merge Changeset: 85df65495177 Author: mcherkas Date: 2013-05-21 03:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85df65495177 7011777: JDK 6 parses html text with script tags within comments differently from previous releases Reviewed-by: alexsch Contributed-by: Dmitry Markov ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/7011777/bug7011777.java Changeset: e36d0b9ed018 Author: alitvinov Date: 2013-05-21 05:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e36d0b9ed018 8005607: Recursion in J2DXErrHandler() Causes a Stack Overflow on Linux Reviewed-by: art, anthony, prr ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XErrorHandler.java + src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTranslateCoordinates.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_GraphicsEnv.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 73d3bed5f8c8 Author: lana Date: 2013-05-22 17:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73d3bed5f8c8 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/lang/Thread/StackTraces.java - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java - test/java/util/logging/bundlesearch/LoadItUp.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 6261e94e9869 Author: alexsch Date: 2013-05-23 15:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6261e94e9869 8014924: JToolTip#setTipText() sometimes (very often) not repaints component. Reviewed-by: serb ! src/share/classes/javax/swing/JToolTip.java Changeset: e8cacde33d27 Author: ant Date: 2013-05-24 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8cacde33d27 8013437: Test sun/awt/datatransfer/SuplementaryCharactersTransferTest.java fails to compile since 8b86 Reviewed-by: alexsch ! test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 6b29c27d0807 Author: malenkov Date: 2013-05-24 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b29c27d0807 8013416: Java Bean Persistence with XMLEncoder Reviewed-by: alexsch ! src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java + test/java/beans/XMLEncoder/Test8013416.java Changeset: c36626831f07 Author: vkarnauk Date: 2013-05-27 12:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c36626831f07 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 70ac1bf74865 Author: serb Date: 2013-05-27 22:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ac1bf74865 8014726: TEST_BUG: java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java should be modified Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! test/java/awt/WMSpecificTests/Metacity/FullscreenDialogModality.java Changeset: ff1c2e379f27 Author: pchelko Date: 2013-05-28 12:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff1c2e379f27 8000422: [macosx] Views keep scrolling back to the drag position after DnD Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: 4f24a4f65a07 Author: anthony Date: 2013-05-28 16:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f24a4f65a07 7039616: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java should be updated Summary: Consider the test passed if the system does not support translucency Reviewed-by: art ! test/java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java Changeset: 1f0628078531 Author: pchelko Date: 2013-05-29 12:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f0628078531 8009911: [macosx] SWT app freeze when going full screen using Java 7 on Mac Reviewed-by: anthony, ksrini ! src/macosx/bin/java_md_macosx.c Changeset: c8a0abc1fd2d Author: mcherkas Date: 2013-05-29 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8a0abc1fd2d 8014863: Line break calculations in Java 7 are incorrect. Reviewed-by: alexp, alexsch Contributed-by: Dmitry Markov ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/View/8014863/bug8014863.java Changeset: aae7b96a350e Author: lana Date: 2013-05-29 16:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aae7b96a350e Merge Changeset: 5d9273a5a84e Author: lana Date: 2013-05-29 16:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d9273a5a84e Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: 7eae7c89dab4 Author: lana Date: 2013-06-03 23:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7eae7c89dab4 Merge - test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Changeset: bb71021af586 Author: lana Date: 2013-06-04 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb71021af586 Merge From sean.coffey at oracle.com Wed Jun 5 08:22:04 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 05 Jun 2013 09:22:04 +0100 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package In-Reply-To: <51AED898.9010104@oracle.com> References: <51AE70BC.3050305@oracle.com> <51AED898.9010104@oracle.com> Message-ID: <51AEF52C.7020301@oracle.com> On 05/06/2013 07:20, Alan Bateman wrote: > On 04/06/2013 23:57, Se?n Coffey wrote: >> The com.sun.corba.se.impl package is a private package. The API is >> subject to change at any time and no 3rd party code should be using >> it. As a result, I'd like to add it to the package restricted list. >> I've run our internal CORBA SQE testsuite against the proposed change >> and didn't see any issues. >> >> bug report : http://bugs.sun.com/view_bug.do?bug_id=8000450 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8/ >> >> I plan to port the same change to jdk7u. > Nobody should be using com.sun.corba.se.impl directly so the change > looks good to me. > > The @summary in the tests suggests it was originally written for JAXP > so if the test scope is extended then that summary will need to be > updated. I also note that the test only uses checkPackageAccess so I > don't think it actually checks entries on the package.definitions > list. We should probably write a more complete test, although I'm not > suggest you have to do this here. There are plans to introduce a more robust testcase to test all restricted packages. Hope to have that brought into jdk8 in coming weeks. Good points on the @summary text. Meant to update that. Test now checks package definition : http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8.2/ regards, Sean. > > -Alan > > From david.holmes at oracle.com Wed Jun 5 08:34:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Jun 2013 18:34:10 +1000 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51AE0582.7030909@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> <51AE0582.7030909@oracle.com> Message-ID: <51AEF802.3010808@oracle.com> This seems fine to me. David On 5/06/2013 1:19 AM, Aleksej Efimov wrote: > Alan, Jason, > Thanks for clarification. I have moved the serial data from binary files > to test class: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ > > > -Aleksej > > On 06/04/2013 05:57 PM, Alan Bateman wrote: >> On 04/06/2013 14:44, Jason Mehrens wrote: >>> Aleksej, >>> >>> Looks good to me. I think Alan wanted you to use the ser files to >>> create a byte array + ByteArrayInputStream in the actual test class >>> instead of including actual serial data files along side the test. >>> >> That would be my preference because we try to avoid binary files in >> the repository. >> >> -Alan. >> >> > From sundararajan.athijegannathan at oracle.com Wed Jun 5 09:40:02 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 05 Jun 2013 09:40:02 +0000 Subject: hg: jdk8/tl/nashorn: 16 new changesets Message-ID: <20130605094015.847BF48F75@hg.openjdk.java.net> Changeset: 66b2fde90c9d Author: jlaskey Date: 2013-05-29 16:23 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66b2fde90c9d 8015636: Add more typed arrays code coverage tests. Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/typedarrays.js Changeset: eda227663eda Author: sundar Date: 2013-05-30 16:49 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eda227663eda 8015353: Date.parse illegal string parsing issues Reviewed-by: jlaskey, lagergren - src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/parser/DateParser.java + test/script/basic/JDK-8015353.js Changeset: 818946884410 Author: attila Date: 2013-05-31 12:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/818946884410 8015693: reduce NodeLiteralNode to NullLiteralNode Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java Changeset: d8a7727a519e Author: attila Date: 2013-05-31 12:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d8a7727a519e 8015684: FieldObjectCreator.putField ignores getValueType Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java Changeset: cab639125b98 Author: attila Date: 2013-05-31 12:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cab639125b98 8015674: CodeGenerator.initSymbols mutates a list Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java Changeset: 11b81fa7125a Author: attila Date: 2013-05-31 12:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/11b81fa7125a 8015673: Type for :e symbol is wrong Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java Changeset: b4e6cc05ce09 Author: sundar Date: 2013-05-31 17:39 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b4e6cc05ce09 8012164: Error.stack needs trimming Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8012164.js + test/script/basic/JDK-8012164.js.EXPECTED ! test/script/basic/NASHORN-108.js.EXPECTED ! test/script/basic/NASHORN-109.js.EXPECTED ! test/script/basic/errorstack.js.EXPECTED Changeset: 64250b3a2f2a Author: jlaskey Date: 2013-05-31 13:04 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/64250b3a2f2a 8015727: Thread safe print function Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/Global.java Changeset: 295c91f5fdde Author: sundar Date: 2013-06-03 15:58 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/295c91f5fdde 8015345: Function("}),print('test'),({") should throw SyntaxError Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8015345.js + test/script/basic/JDK-8015345.js.EXPECTED ! test/script/basic/funcconstructor.js.EXPECTED Changeset: 08a8fda6c0bf Author: jlaskey Date: 2013-06-03 08:34 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/08a8fda6c0bf 8015741: Need a global.load function that starts with a new global scope. Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8015741.js + test/script/basic/JDK-8015741.js.EXPECTED Changeset: 2df08f4c531d Author: jlaskey Date: 2013-06-03 11:16 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2df08f4c531d 8015796: Race condition in RuntimeCallsites Reviewed-by: lagergren, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java Changeset: 0946c8a60f39 Author: jlaskey Date: 2013-06-03 12:57 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0946c8a60f39 8015814: loadWithNewGlobal needs to wrap createGlobal in AccessController.doPrivileged Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 78113cda23bf Author: sundar Date: 2013-06-04 17:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/78113cda23bf 8015855: test/script/basic/JDK-8012164.js fails on Windows Reviewed-by: hannesw, lagergren, jlaskey ! test/script/basic/JDK-8012164.js Changeset: c70f60578385 Author: sundar Date: 2013-06-04 22:31 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c70f60578385 8015830: Javascript mapping of ScriptEngine bindings does not expose keys Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8015830.js + test/script/basic/JDK-8015830.js.EXPECTED Changeset: 62b096f7bac3 Author: sundar Date: 2013-06-05 12:08 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/62b096f7bac3 8015945: loadWithNewGlobal return value has to be properly wrapped Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8015945.js + test/script/basic/JDK-8015945.js.EXPECTED Changeset: c6c05f23bca4 Author: sundar Date: 2013-06-05 13:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c6c05f23bca4 Merge - src/jdk/nashorn/internal/objects/DateParser.java From Alan.Bateman at oracle.com Wed Jun 5 10:09:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Jun 2013 11:09:47 +0100 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51AE0582.7030909@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> <51AE0582.7030909@oracle.com> Message-ID: <51AF0E6B.3030305@oracle.com> On 04/06/2013 16:19, Aleksej Efimov wrote: > Alan, Jason, > Thanks for clarification. I have moved the serial data from binary > files to test class: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ > > > -Aleksej > Thanks, this looks much better. Just a few remaining comments on the test: - It needs a copyright header - I think twocauses and normaljdk7ser should have a comment to detail how the bytes are generated. One idea (and you'll see this in a few other tests) is to have an option to the test to generate the bytes. Alternatively put the code in comments so that anyone can re-generate them if needed. As they are constants then they can be final and probably should be in uppercase. Otherwise I think this is good to go. -Alan. From alan.bateman at oracle.com Wed Jun 5 10:14:12 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 05 Jun 2013 10:14:12 +0000 Subject: hg: jdk8/tl/jdk: 8003895: java/nio/channels/AsynchronousChannelGroup/Unbounded.java failing again [win64] Message-ID: <20130605101435.8EF6848F7A@hg.openjdk.java.net> Changeset: 8a9f897a57d6 Author: alanb Date: 2013-06-05 11:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a9f897a57d6 8003895: java/nio/channels/AsynchronousChannelGroup/Unbounded.java failing again [win64] Reviewed-by: chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java From chris.hegarty at oracle.com Wed Jun 5 10:42:50 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 05 Jun 2013 11:42:50 +0100 Subject: 8015963: Add at since tags to new ConcurrentHashMap methods Message-ID: <51AF162A.6030004@oracle.com> Just some minor cleanup after the integration of CHMv8. Trivially, add @since 1.8 tags to the 34 new methods and 1 new class in ConcurrentHashMap. http://cr.openjdk.java.net/~chegar/8015963/webrev.00/webrev/src/share/classes/java/util/concurrent/ConcurrentHashMap.java.udiff.html Doug, Here is a patch based on you CVS. RCS file: /home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java,v retrieving revision 1.219 diff -u -r1.219 ConcurrentHashMap.java --- ConcurrentHashMap.java 1 Jun 2013 18:19:08 -0000 1.219 +++ ConcurrentHashMap.java 5 Jun 2013 10:31:56 -0000 @@ -2578,6 +2578,8 @@ * from the given type to {@code Boolean.TRUE}. * * @return the new set + * + * @since 1.8 */ public static KeySetView newKeySet() { return new KeySetView @@ -2593,6 +2595,8 @@ * @throws IllegalArgumentException if the initial capacity of * elements is negative * @return the new set + * + * @since 1.8 */ public static KeySetView newKeySet(int initialCapacity) { return new KeySetView @@ -2624,6 +2628,8 @@ * there are concurrent insertions or removals. * * @return the number of mappings + * + * @since 1.8 */ public long mappingCount() { long n = sumCount(); @@ -3293,6 +3299,8 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * + * @since 1.8 */ public void forEach(long parallelismThreshold, BiConsumer action) { @@ -3312,6 +3320,8 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * + * @since 1.8 */ public void forEach(long parallelismThreshold, BiFunction transformer, @@ -3336,6 +3346,8 @@ * result on success, else null * @return a non-null result from applying the given search * function on each (key, value), or null if none + * + * @since 1.8 */ public U search(long parallelismThreshold, BiFunction searchFunction) { @@ -3358,6 +3370,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * + * @since 1.8 */ public U reduce(long parallelismThreshold, BiFunction transformer, @@ -3382,6 +3396,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * + * @since 1.8 */ public double reduceToDoubleIn(long parallelismThreshold, ToDoubleBiFunction transformer, @@ -3407,6 +3423,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * + * @since 1.8 */ public long reduceToLong(long parallelismThreshold, ToLongBiFunction transformer, @@ -3432,6 +3450,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * + * @since 1.8 */ public int reduceToInt(long parallelismThreshold, ToIntBiFunction transformer, @@ -3450,6 +3470,8 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * + * @since 1.8 */ public void forEachKey(long parallelismThreshold, Consumer action) { @@ -3469,6 +3491,8 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * + * @since 1.8 */ public void forEachKey(long parallelismThreshold, Function transformer, @@ -3493,6 +3517,8 @@ * result on success, else null * @return a non-null result from applying the given search * function on each key, or null if none + * + * @since 1.8 */ public U searchKeys(long parallelismThreshold, Function searchFunction) { @@ -3511,6 +3537,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating all keys using the given * reducer to combine values, or null if none + * + * @since 1.8 */ public K reduceKeys(long parallelismThreshold, BiFunction reducer) { @@ -3533,6 +3561,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * + * @since 1.8 */ public U reduceKeys(long parallelismThreshold, Function transformer, @@ -3557,6 +3587,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * + * @since 1.8 */ public double reduceKeysToDouble(long parallelismThreshold, ToDoubleFunction transformer, @@ -3582,6 +3614,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * + * @since 1.8 */ public long reduceKeysToLong(long parallelismThreshold, ToLongFunction transformer, @@ -3607,6 +3641,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * + * @since 1.8 */ public int reduceKeysToInt(long parallelismThreshold, ToIntFunction transformer, @@ -3625,6 +3661,8 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * + * @since 1.8 */ public void forEachValue(long parallelismThreshold, Consumer action) { @@ -3645,6 +3683,8 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * + * @since 1.8 */ public void forEachValue(long parallelismThreshold, Function transformer, @@ -3669,6 +3709,8 @@ * result on success, else null * @return a non-null result from applying the given search * function on each value, or null if none + * + * @since 1.8 */ public U searchValues(long parallelismThreshold, Function searchFunction) { @@ -3686,6 +3728,8 @@ * needed for this operation to be executed in parallel * @param reducer a commutative associative combining function * @return the result of accumulating all values + * + * @since 1.8 */ public V reduceValues(long parallelismThreshold, BiFunction reducer) { @@ -3708,6 +3752,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * + * @since 1.8 */ public U reduceValues(long parallelismThreshold, Function transformer, @@ -3732,6 +3778,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * + * @since 1.8 */ public double reduceValuesToDouble(long parallelismThreshold, ToDoubleFunction transformer, @@ -3757,6 +3805,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * + * @since 1.8 */ public long reduceValuesToLong(long parallelismThreshold, ToLongFunction transformer, @@ -3782,6 +3832,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * + * @since 1.8 */ public int reduceValuesToInt(long parallelismThreshold, ToIntFunction transformer, @@ -3800,6 +3852,8 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * + * @since 1.8 */ public void forEachEntry(long parallelismThreshold, Consumer> action) { @@ -3818,6 +3872,8 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * + * @since 1.8 */ public void forEachEntry(long parallelismThreshold, Function, ? extends U> transformer, @@ -3842,6 +3898,8 @@ * result on success, else null * @return a non-null result from applying the given search * function on each entry, or null if none + * + * @since 1.8 */ public U searchEntries(long parallelismThreshold, Function, ? extends U> searchFunction) { @@ -3859,6 +3917,8 @@ * needed for this operation to be executed in parallel * @param reducer a commutative associative combining function * @return the result of accumulating all entries + * + * @since 1.8 */ public Map.Entry reduceEntries(long parallelismThreshold, BiFunction, Map.Entry, ? extends Map.Entry> reducer) { @@ -3881,6 +3941,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * + * @since 1.8 */ public U reduceEntries(long parallelismThreshold, Function, ? extends U> transformer, @@ -3905,6 +3967,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * + * @since 1.8 */ public double reduceEntriesToDouble(long parallelismThreshold, ToDoubleFunction> transformer, @@ -3930,6 +3994,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * + * @since 1.8 */ public long reduceEntriesToLong(long parallelismThreshold, ToLongFunction> transformer, @@ -3955,6 +4021,8 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * + * @since 1.8 */ public int reduceEntriesToInt(long parallelismThreshold, ToIntFunction> transformer, @@ -4130,6 +4198,8 @@ * {@link #keySet(Object) keySet(V)}, * {@link #newKeySet() newKeySet()}, * {@link #newKeySet(int) newKeySet(int)}. + * + * @since 1.8 */ public static class KeySetView extends CollectionView implements Set, java.io.Serializable { -Chris. From paul.sandoz at oracle.com Wed Jun 5 10:40:53 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 05 Jun 2013 10:40:53 +0000 Subject: hg: jdk8/tl/jdk: 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining() Message-ID: <20130605104105.AD39E48F7D@hg.openjdk.java.net> Changeset: de11b20f8c01 Author: psandoz Date: 2013-05-31 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de11b20f8c01 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining() Reviewed-by: chegar ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/WeakHashMap.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java From alexander.zuev at oracle.com Wed Jun 5 12:58:34 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Wed, 05 Jun 2013 12:58:34 +0000 Subject: hg: jdk8/tl/langtools: 7186887: Test T6567415.java can fail on a slow machine Message-ID: <20130605125842.F3F1648F84@hg.openjdk.java.net> Changeset: 79fd9cfa55f2 Author: kizune Date: 2013-06-05 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79fd9cfa55f2 7186887: Test T6567415.java can fail on a slow machine Reviewed-by: jjg, ksrini ! test/tools/javac/6567415/T6567415.java From alan.bateman at oracle.com Wed Jun 5 12:58:52 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 05 Jun 2013 12:58:52 +0000 Subject: hg: jdk8/tl/jdk: 8015880: GenerateBreakIteratorData build warning Message-ID: <20130605125928.936D448F86@hg.openjdk.java.net> Changeset: ae700bdb68b6 Author: alanb Date: 2013-06-05 13:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae700bdb68b6 8015880: GenerateBreakIteratorData build warning Reviewed-by: peytoia ! make/tools/src/build/tools/generatebreakiteratordata/CharSet.java From paul.sandoz at oracle.com Wed Jun 5 13:10:45 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Jun 2013 15:10:45 +0200 Subject: RFR 8015895 Int/LongStream.range/rangeClosed Message-ID: Hi, The following was decided by the JSR-335 EG: 1) Int/LongStream.range are restricted to a fixed step of 1. The map operation can be used to adjust the step. 2) Int/LongStream.rangeClosed methods were added for a closed range with a fixed step of 1, in addition to the half open range of 1). http://cr.openjdk.java.net/~psandoz/tl/JDK-8015895-rangeClosed/webrev/ The range spliterator implementations also have some biasing of the splits for large ranges, since the larger the range the more likely it will be used in conjunction with limit or another form of short-circuiting operation. This was intentionally kept simple for the moment: a ratio of 1:7 in size for left:right when the size is > 2^24. There is some code commented out in the implementation and tests which will be uncommented once Stream concatenation makes it's way into TL. I wanted to get this in sooner rather than be blocked waiting on concatenation. Stream concatenation will be used in LongStream for edge cases when the range is > Long.MAX_VALUE e.g. LongStream.range(Long.MIN_VALUE, Long.MAX_VALUE), LongStream.rangeClosed(0, Long.MAX_VALUE). This webrev is layered on top of: http://cr.openjdk.java.net/~psandoz/tl/JDK-8015492-rm-DoubleStream.range/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8015798-asXxxStream/webrev/ Paul. From aleksey.shipilev at oracle.com Wed Jun 5 13:39:55 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Jun 2013 17:39:55 +0400 Subject: 8015963: Add at since tags to new ConcurrentHashMap methods In-Reply-To: <51AF162A.6030004@oracle.com> References: <51AF162A.6030004@oracle.com> Message-ID: <51AF3FAB.8020601@oracle.com> Looks good to me. -Aleksey. On 06/05/2013 02:42 PM, Chris Hegarty wrote: > Just some minor cleanup after the integration of CHMv8. Trivially, add > @since 1.8 tags to the 34 new methods and 1 new class in ConcurrentHashMap. > > http://cr.openjdk.java.net/~chegar/8015963/webrev.00/webrev/src/share/classes/java/util/concurrent/ConcurrentHashMap.java.udiff.html > > > Doug, > Here is a patch based on you CVS. > > RCS file: > /home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java,v > > retrieving revision 1.219 > diff -u -r1.219 ConcurrentHashMap.java > --- ConcurrentHashMap.java 1 Jun 2013 18:19:08 -0000 1.219 > +++ ConcurrentHashMap.java 5 Jun 2013 10:31:56 -0000 > @@ -2578,6 +2578,8 @@ > * from the given type to {@code Boolean.TRUE}. > * > * @return the new set > + * > + * @since 1.8 > */ > public static KeySetView newKeySet() { > return new KeySetView > @@ -2593,6 +2595,8 @@ > * @throws IllegalArgumentException if the initial capacity of > * elements is negative > * @return the new set > + * > + * @since 1.8 > */ > public static KeySetView newKeySet(int > initialCapacity) { > return new KeySetView > @@ -2624,6 +2628,8 @@ > * there are concurrent insertions or removals. > * > * @return the number of mappings > + * > + * @since 1.8 > */ > public long mappingCount() { > long n = sumCount(); > @@ -3293,6 +3299,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEach(long parallelismThreshold, > BiConsumer action) { > @@ -3312,6 +3320,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEach(long parallelismThreshold, > BiFunction U> transformer, > @@ -3336,6 +3346,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each (key, value), or null if none > + * > + * @since 1.8 > */ > public U search(long parallelismThreshold, > BiFunction > searchFunction) { > @@ -3358,6 +3370,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public U reduce(long parallelismThreshold, > BiFunction > transformer, > @@ -3382,6 +3396,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public double reduceToDoubleIn(long parallelismThreshold, > ToDoubleBiFunction super V> transformer, > @@ -3407,6 +3423,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public long reduceToLong(long parallelismThreshold, > ToLongBiFunction > transformer, > @@ -3432,6 +3450,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public int reduceToInt(long parallelismThreshold, > ToIntBiFunction > transformer, > @@ -3450,6 +3470,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachKey(long parallelismThreshold, > Consumer action) { > @@ -3469,6 +3491,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachKey(long parallelismThreshold, > Function > transformer, > @@ -3493,6 +3517,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each key, or null if none > + * > + * @since 1.8 > */ > public U searchKeys(long parallelismThreshold, > Function > searchFunction) { > @@ -3511,6 +3537,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating all keys using the given > * reducer to combine values, or null if none > + * > + * @since 1.8 > */ > public K reduceKeys(long parallelismThreshold, > BiFunction > reducer) { > @@ -3533,6 +3561,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public U reduceKeys(long parallelismThreshold, > Function transformer, > @@ -3557,6 +3587,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public double reduceKeysToDouble(long parallelismThreshold, > ToDoubleFunction > transformer, > @@ -3582,6 +3614,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public long reduceKeysToLong(long parallelismThreshold, > ToLongFunction transformer, > @@ -3607,6 +3641,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public int reduceKeysToInt(long parallelismThreshold, > ToIntFunction transformer, > @@ -3625,6 +3661,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachValue(long parallelismThreshold, > Consumer action) { > @@ -3645,6 +3683,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachValue(long parallelismThreshold, > Function > transformer, > @@ -3669,6 +3709,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each value, or null if none > + * > + * @since 1.8 > */ > public U searchValues(long parallelismThreshold, > Function > searchFunction) { > @@ -3686,6 +3728,8 @@ > * needed for this operation to be executed in parallel > * @param reducer a commutative associative combining function > * @return the result of accumulating all values > + * > + * @since 1.8 > */ > public V reduceValues(long parallelismThreshold, > BiFunction > reducer) { > @@ -3708,6 +3752,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public U reduceValues(long parallelismThreshold, > Function > transformer, > @@ -3732,6 +3778,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public double reduceValuesToDouble(long parallelismThreshold, > ToDoubleFunction > transformer, > @@ -3757,6 +3805,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public long reduceValuesToLong(long parallelismThreshold, > ToLongFunction transformer, > @@ -3782,6 +3832,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public int reduceValuesToInt(long parallelismThreshold, > ToIntFunction transformer, > @@ -3800,6 +3852,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachEntry(long parallelismThreshold, > Consumer> action) { > @@ -3818,6 +3872,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachEntry(long parallelismThreshold, > Function, ? extends U> > transformer, > @@ -3842,6 +3898,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each entry, or null if none > + * > + * @since 1.8 > */ > public U searchEntries(long parallelismThreshold, > Function, ? extends U> > searchFunction) { > @@ -3859,6 +3917,8 @@ > * needed for this operation to be executed in parallel > * @param reducer a commutative associative combining function > * @return the result of accumulating all entries > + * > + * @since 1.8 > */ > public Map.Entry reduceEntries(long parallelismThreshold, > BiFunction, > Map.Entry, ? extends Map.Entry> reducer) { > @@ -3881,6 +3941,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public U reduceEntries(long parallelismThreshold, > Function, ? extends U> > transformer, > @@ -3905,6 +3967,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public double reduceEntriesToDouble(long parallelismThreshold, > > ToDoubleFunction> transformer, > @@ -3930,6 +3994,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public long reduceEntriesToLong(long parallelismThreshold, > ToLongFunction> > transformer, > @@ -3955,6 +4021,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public int reduceEntriesToInt(long parallelismThreshold, > ToIntFunction> > transformer, > @@ -4130,6 +4198,8 @@ > * {@link #keySet(Object) keySet(V)}, > * {@link #newKeySet() newKeySet()}, > * {@link #newKeySet(int) newKeySet(int)}. > + * > + * @since 1.8 > */ > public static class KeySetView extends CollectionView > implements Set, java.io.Serializable { > > -Chris. > > > From martinrb at google.com Wed Jun 5 13:49:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 5 Jun 2013 06:49:40 -0700 Subject: 8015963: Add at since tags to new ConcurrentHashMap methods In-Reply-To: <51AF162A.6030004@oracle.com> References: <51AF162A.6030004@oracle.com> Message-ID: jsr166 CVS updated with this patch, except that the jsr166 style is not to introduce a blank line just for @since. (Like I keep saying, revive/open-source my old missing-at-since finder or find a more principled way of finding these) Index: ConcurrentHashMap.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java,v retrieving revision 1.219 diff -u -r1.219 ConcurrentHashMap.java --- ConcurrentHashMap.java 1 Jun 2013 18:19:08 -0000 1.219 +++ ConcurrentHashMap.java 5 Jun 2013 13:44:59 -0000 @@ -2578,6 +2578,7 @@ * from the given type to {@code Boolean.TRUE}. * * @return the new set + * @since 1.8 */ public static KeySetView newKeySet() { return new KeySetView @@ -2593,6 +2594,7 @@ * @throws IllegalArgumentException if the initial capacity of * elements is negative * @return the new set + * @since 1.8 */ public static KeySetView newKeySet(int initialCapacity) { return new KeySetView @@ -2624,6 +2626,7 @@ * there are concurrent insertions or removals. * * @return the number of mappings + * @since 1.8 */ public long mappingCount() { long n = sumCount(); @@ -3293,6 +3296,7 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * @since 1.8 */ public void forEach(long parallelismThreshold, BiConsumer action) { @@ -3312,6 +3316,7 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * @since 1.8 */ public void forEach(long parallelismThreshold, BiFunction transformer, @@ -3336,6 +3341,7 @@ * result on success, else null * @return a non-null result from applying the given search * function on each (key, value), or null if none + * @since 1.8 */ public U search(long parallelismThreshold, BiFunction searchFunction) { @@ -3358,6 +3364,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * @since 1.8 */ public U reduce(long parallelismThreshold, BiFunction transformer, @@ -3382,6 +3389,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * @since 1.8 */ public double reduceToDoubleIn(long parallelismThreshold, ToDoubleBiFunction transformer, @@ -3407,6 +3415,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * @since 1.8 */ public long reduceToLong(long parallelismThreshold, ToLongBiFunction transformer, @@ -3432,6 +3441,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all (key, value) pairs + * @since 1.8 */ public int reduceToInt(long parallelismThreshold, ToIntBiFunction transformer, @@ -3450,6 +3460,7 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * @since 1.8 */ public void forEachKey(long parallelismThreshold, Consumer action) { @@ -3469,6 +3480,7 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * @since 1.8 */ public void forEachKey(long parallelismThreshold, Function transformer, @@ -3493,6 +3505,7 @@ * result on success, else null * @return a non-null result from applying the given search * function on each key, or null if none + * @since 1.8 */ public U searchKeys(long parallelismThreshold, Function searchFunction) { @@ -3511,6 +3524,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating all keys using the given * reducer to combine values, or null if none + * @since 1.8 */ public K reduceKeys(long parallelismThreshold, BiFunction reducer) { @@ -3533,6 +3547,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * @since 1.8 */ public U reduceKeys(long parallelismThreshold, Function transformer, @@ -3557,6 +3572,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * @since 1.8 */ public double reduceKeysToDouble(long parallelismThreshold, ToDoubleFunction transformer, @@ -3582,6 +3598,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * @since 1.8 */ public long reduceKeysToLong(long parallelismThreshold, ToLongFunction transformer, @@ -3607,6 +3624,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all keys + * @since 1.8 */ public int reduceKeysToInt(long parallelismThreshold, ToIntFunction transformer, @@ -3625,6 +3643,7 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * @since 1.8 */ public void forEachValue(long parallelismThreshold, Consumer action) { @@ -3645,6 +3664,7 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * @since 1.8 */ public void forEachValue(long parallelismThreshold, Function transformer, @@ -3669,6 +3689,7 @@ * result on success, else null * @return a non-null result from applying the given search * function on each value, or null if none + * @since 1.8 */ public U searchValues(long parallelismThreshold, Function searchFunction) { @@ -3686,6 +3707,7 @@ * needed for this operation to be executed in parallel * @param reducer a commutative associative combining function * @return the result of accumulating all values + * @since 1.8 */ public V reduceValues(long parallelismThreshold, BiFunction reducer) { @@ -3708,6 +3730,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * @since 1.8 */ public U reduceValues(long parallelismThreshold, Function transformer, @@ -3732,6 +3755,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * @since 1.8 */ public double reduceValuesToDouble(long parallelismThreshold, ToDoubleFunction transformer, @@ -3757,6 +3781,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * @since 1.8 */ public long reduceValuesToLong(long parallelismThreshold, ToLongFunction transformer, @@ -3782,6 +3807,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all values + * @since 1.8 */ public int reduceValuesToInt(long parallelismThreshold, ToIntFunction transformer, @@ -3800,6 +3826,7 @@ * @param parallelismThreshold the (estimated) number of elements * needed for this operation to be executed in parallel * @param action the action + * @since 1.8 */ public void forEachEntry(long parallelismThreshold, Consumer> action) { @@ -3818,6 +3845,7 @@ * for an element, or null if there is no transformation (in * which case the action is not applied) * @param action the action + * @since 1.8 */ public void forEachEntry(long parallelismThreshold, Function, ? extends U> transformer, @@ -3842,6 +3870,7 @@ * result on success, else null * @return a non-null result from applying the given search * function on each entry, or null if none + * @since 1.8 */ public U searchEntries(long parallelismThreshold, Function, ? extends U> searchFunction) { @@ -3859,6 +3888,7 @@ * needed for this operation to be executed in parallel * @param reducer a commutative associative combining function * @return the result of accumulating all entries + * @since 1.8 */ public Map.Entry reduceEntries(long parallelismThreshold, BiFunction, Map.Entry, ? extends Map.Entry> reducer) { @@ -3881,6 +3911,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * @since 1.8 */ public U reduceEntries(long parallelismThreshold, Function, ? extends U> transformer, @@ -3905,6 +3936,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * @since 1.8 */ public double reduceEntriesToDouble(long parallelismThreshold, ToDoubleFunction> transformer, On Wed, Jun 5, 2013 at 3:42 AM, Chris Hegarty wrote: > Just some minor cleanup after the integration of CHMv8. Trivially, add > @since 1.8 tags to the 34 new methods and 1 new class in ConcurrentHashMap. > > http://cr.openjdk.java.net/~**chegar/8015963/webrev.00/** > webrev/src/share/classes/java/**util/concurrent/** > ConcurrentHashMap.java.udiff.**html > > Doug, > Here is a patch based on you CVS. > > RCS file: /home/jsr166/jsr166/jsr166/**src/main/java/util/concurrent/** > ConcurrentHashMap.java,v > retrieving revision 1.219 > diff -u -r1.219 ConcurrentHashMap.java > --- ConcurrentHashMap.java 1 Jun 2013 18:19:08 -0000 1.219 > +++ ConcurrentHashMap.java 5 Jun 2013 10:31:56 -0000 > @@ -2578,6 +2578,8 @@ > * from the given type to {@code Boolean.TRUE}. > * > * @return the new set > + * > + * @since 1.8 > */ > public static KeySetView newKeySet() { > return new KeySetView > @@ -2593,6 +2595,8 @@ > * @throws IllegalArgumentException if the initial capacity of > * elements is negative > * @return the new set > + * > + * @since 1.8 > */ > public static KeySetView newKeySet(int > initialCapacity) { > return new KeySetView > @@ -2624,6 +2628,8 @@ > * there are concurrent insertions or removals. > * > * @return the number of mappings > + * > + * @since 1.8 > */ > public long mappingCount() { > long n = sumCount(); > @@ -3293,6 +3299,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEach(long parallelismThreshold, > BiConsumer action) { > @@ -3312,6 +3320,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEach(long parallelismThreshold, > BiFunction > transformer, > @@ -3336,6 +3346,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each (key, value), or null if none > + * > + * @since 1.8 > */ > public U search(long parallelismThreshold, > BiFunction > searchFunction) { > @@ -3358,6 +3370,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public U reduce(long parallelismThreshold, > BiFunction > transformer, > @@ -3382,6 +3396,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public double reduceToDoubleIn(long parallelismThreshold, > ToDoubleBiFunction V> transformer, > @@ -3407,6 +3423,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public long reduceToLong(long parallelismThreshold, > ToLongBiFunction > transformer, > @@ -3432,6 +3450,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all (key, value) pairs > + * > + * @since 1.8 > */ > public int reduceToInt(long parallelismThreshold, > ToIntBiFunction > transformer, > @@ -3450,6 +3470,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachKey(long parallelismThreshold, > Consumer action) { > @@ -3469,6 +3491,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachKey(long parallelismThreshold, > Function > transformer, > @@ -3493,6 +3517,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each key, or null if none > + * > + * @since 1.8 > */ > public U searchKeys(long parallelismThreshold, > Function > searchFunction) { > @@ -3511,6 +3537,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating all keys using the given > * reducer to combine values, or null if none > + * > + * @since 1.8 > */ > public K reduceKeys(long parallelismThreshold, > BiFunction > reducer) { > @@ -3533,6 +3561,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public U reduceKeys(long parallelismThreshold, > Function transformer, > @@ -3557,6 +3587,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public double reduceKeysToDouble(long parallelismThreshold, > ToDoubleFunction > transformer, > @@ -3582,6 +3614,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public long reduceKeysToLong(long parallelismThreshold, > ToLongFunction transformer, > @@ -3607,6 +3641,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all keys > + * > + * @since 1.8 > */ > public int reduceKeysToInt(long parallelismThreshold, > ToIntFunction transformer, > @@ -3625,6 +3661,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachValue(long parallelismThreshold, > Consumer action) { > @@ -3645,6 +3683,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachValue(long parallelismThreshold, > Function > transformer, > @@ -3669,6 +3709,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each value, or null if none > + * > + * @since 1.8 > */ > public U searchValues(long parallelismThreshold, > Function > searchFunction) { > @@ -3686,6 +3728,8 @@ > * needed for this operation to be executed in parallel > * @param reducer a commutative associative combining function > * @return the result of accumulating all values > + * > + * @since 1.8 > */ > public V reduceValues(long parallelismThreshold, > BiFunction > reducer) { > @@ -3708,6 +3752,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public U reduceValues(long parallelismThreshold, > Function > transformer, > @@ -3732,6 +3778,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public double reduceValuesToDouble(long parallelismThreshold, > ToDoubleFunction > transformer, > @@ -3757,6 +3805,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public long reduceValuesToLong(long parallelismThreshold, > ToLongFunction transformer, > @@ -3782,6 +3832,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all values > + * > + * @since 1.8 > */ > public int reduceValuesToInt(long parallelismThreshold, > ToIntFunction transformer, > @@ -3800,6 +3852,8 @@ > * @param parallelismThreshold the (estimated) number of elements > * needed for this operation to be executed in parallel > * @param action the action > + * > + * @since 1.8 > */ > public void forEachEntry(long parallelismThreshold, > Consumer> action) { > @@ -3818,6 +3872,8 @@ > * for an element, or null if there is no transformation (in > * which case the action is not applied) > * @param action the action > + * > + * @since 1.8 > */ > public void forEachEntry(long parallelismThreshold, > Function, ? extends U> > transformer, > @@ -3842,6 +3898,8 @@ > * result on success, else null > * @return a non-null result from applying the given search > * function on each entry, or null if none > + * > + * @since 1.8 > */ > public U searchEntries(long parallelismThreshold, > Function, ? extends U> > searchFunction) { > @@ -3859,6 +3917,8 @@ > * needed for this operation to be executed in parallel > * @param reducer a commutative associative combining function > * @return the result of accumulating all entries > + * > + * @since 1.8 > */ > public Map.Entry reduceEntries(long parallelismThreshold, > BiFunction, > Map.Entry, ? extends Map.Entry> reducer) { > @@ -3881,6 +3941,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public U reduceEntries(long parallelismThreshold, > Function, ? extends U> > transformer, > @@ -3905,6 +3967,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public double reduceEntriesToDouble(long parallelismThreshold, > > ToDoubleFunction> transformer, > @@ -3930,6 +3994,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public long reduceEntriesToLong(long parallelismThreshold, > ToLongFunction> > transformer, > @@ -3955,6 +4021,8 @@ > * @param reducer a commutative associative combining function > * @return the result of accumulating the given transformation > * of all entries > + * > + * @since 1.8 > */ > public int reduceEntriesToInt(long parallelismThreshold, > ToIntFunction> > transformer, > @@ -4130,6 +4198,8 @@ > * {@link #keySet(Object) keySet(V)}, > * {@link #newKeySet() newKeySet()}, > * {@link #newKeySet(int) newKeySet(int)}. > + * > + * @since 1.8 > */ > public static class KeySetView extends CollectionView > implements Set, java.io.Serializable { > > -Chris. > > > > From dmitry.samersoff at oracle.com Wed Jun 5 14:21:01 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 05 Jun 2013 14:21:01 +0000 Subject: hg: jdk8/tl/jdk: 8015604: JDP packets containing ideographic characters are broken Message-ID: <20130605142131.6BEF348F96@hg.openjdk.java.net> Changeset: df1b35c7901d Author: dsamersoff Date: 2013-06-05 18:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df1b35c7901d 8015604: JDP packets containing ideographic characters are broken Summary: Code uses string length rather than byte array length and non ascii entry brakes packet. Reviewed-by: dholmes, jbachorik, sla ! src/share/classes/sun/management/jdp/JdpPacketWriter.java ! test/sun/management/jdp/JdpUnitTest.java From chris.hegarty at oracle.com Wed Jun 5 14:35:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Jun 2013 07:35:43 -0700 (PDT) Subject: 8015963: Add at since tags to new ConcurrentHashMap methods In-Reply-To: References: <51AF162A.6030004@oracle.com> Message-ID: <51AF4CBF.30603@oracle.com> On 05/06/2013 14:49, Martin Buchholz wrote: > jsr166 CVS updated with this patch, except that the jsr166 style is not > to introduce a blank line just for @since. Thanks Martin, Trivially, I think you are still missing a few: reduceEntriesToLong, reduceEntriesToInt, and class KeySetView. Thanks, -Chris. P.S. I am working on locating your original scripts for finding these. From chris.hegarty at oracle.com Wed Jun 5 15:07:58 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 05 Jun 2013 15:07:58 +0000 Subject: hg: jdk8/tl/jdk: 8011719: Properties.loadFromXML fails with a chunked HTTP connection Message-ID: <20130605150811.0691948F9A@hg.openjdk.java.net> Changeset: 5edcc8ca4146 Author: chegar Date: 2013-06-05 16:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5edcc8ca4146 8011719: Properties.loadFromXML fails with a chunked HTTP connection Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpStreams.java From brian.burkhalter at oracle.com Wed Jun 5 15:13:21 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2013 08:13:21 -0700 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <51AF02C4.1050202@oracle.com> References: <51ADA70F.7040208@oracle.com> <51ADF04E.7060605@oracle.com> <51AF02C4.1050202@oracle.com> Message-ID: <4852D6C7-C0CF-4581-A862-CACBD2A09423@oracle.com> Hi Sergey, Thanks for the comments and suggestions. On Jun 5, 2013, at 2:20 AM, Aleksey Shipilev wrote: > Sergey will follow up on the benchmark itself, I'm just being > nit-picking below (not that it helps performance, but it does contribute > to cleaner benchmark code): > a) if you only have the single State, you might as well use the > benchmark instance itself to be the @State I knew about @State but simply had not changed the test accordingly. > b) the annotations you are using on each method, can flow up to > class-level annotation, and will be inherited by all the @GMB methods; I was not aware of this. > c) it is a good idea to initialize the State fields within the @Setup > method, because we guarantee correct initialization JMM-wise (try to run > your benchmark on non-x86 hardware, and you can occasionally see the > NPEs, because genericFactor1/2 might be null; you can also make the same > effect with "final" on fields, but that wouldn't be the generic case). That is good to know also. I read about State Fixtures but did not know of this behavior. > Here's the complete code: I'll try this updated version and see whether there is any change. Thanks, Brian From chris.hegarty at oracle.com Wed Jun 5 15:25:06 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 05 Jun 2013 15:25:06 +0000 Subject: hg: jdk8/tl/jdk: 8015963: Add at since tags to new ConcurrentHashMap methods Message-ID: <20130605152518.AC06D48F9F@hg.openjdk.java.net> Changeset: c1af6b5a979a Author: chegar Date: 2013-06-05 16:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1af6b5a979a 8015963: Add at since tags to new ConcurrentHashMap methods Reviewed-by: shade, martin ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From aleksey.shipilev at oracle.com Wed Jun 5 15:26:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 05 Jun 2013 19:26:43 +0400 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <4852D6C7-C0CF-4581-A862-CACBD2A09423@oracle.com> References: <51ADA70F.7040208@oracle.com> <51ADF04E.7060605@oracle.com> <51AF02C4.1050202@oracle.com> <4852D6C7-C0CF-4581-A862-CACBD2A09423@oracle.com> Message-ID: <51AF58B3.2060408@oracle.com> On 06/05/2013 07:13 PM, Brian Burkhalter wrote: > Hi Sergey, Aleksey :) >> b) the annotations you are using on each method, can flow up to >> class-level annotation, and will be inherited by all the @GMB methods; > > I was not aware of this. Yes, and with the daizy-fresh JMH, it is even possible to move the remaining data upwards to the class level: http://mail.openjdk.java.net/pipermail/jmh-dev/2013-June/000074.html >> c) it is a good idea to initialize the State fields within the @Setup >> method, because we guarantee correct initialization JMM-wise (try to run >> your benchmark on non-x86 hardware, and you can occasionally see the >> NPEs, because genericFactor1/2 might be null; you can also make the same >> effect with "final" on fields, but that wouldn't be the generic case). > > That is good to know also. I read about State Fixtures but did not know > of this behavior. I take that back, the JMH samples are correct. JMH will initialize the states with the worker threads, and publish it properly for you. You can keep the init the way you have it now. The only culprit is that if State is getting reused between the benchmark runs, it is a good idea to re-initialize it with @Setup. But, since BigIntegers are "immutable", you don't actually care. -Aleksey. From frederic.parain at oracle.com Wed Jun 5 15:41:32 2013 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 05 Jun 2013 15:41:32 +0000 Subject: hg: jdk8/tl/jdk: 7150256: Add back Diagnostic Command JMX API Message-ID: <20130605154144.A815E48FA0@hg.openjdk.java.net> Changeset: e857b2a3ecee Author: fparain Date: 2013-06-05 08:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e857b2a3ecee 7150256: Add back Diagnostic Command JMX API Reviewed-by: mchung, jbachorik ! make/java/management/Exportedfiles.gmk ! make/java/management/FILES_c.gmk ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers + src/share/classes/com/sun/management/DiagnosticCommandMBean.java ! src/share/classes/java/lang/management/ManagementFactory.java + src/share/classes/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/sun/management/DiagnosticCommandImpl.java + src/share/classes/sun/management/DiagnosticCommandInfo.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h + src/share/native/sun/management/DiagnosticCommandImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java + test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java ! test/java/lang/management/MXBean/MXBeanBehavior.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java From james.laskey at oracle.com Wed Jun 5 15:56:03 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Wed, 05 Jun 2013 15:56:03 +0000 Subject: hg: jdk8/tl/nashorn: 6 new changesets Message-ID: <20130605155608.E354148FA2@hg.openjdk.java.net> Changeset: 0feca8a93cb3 Author: attila Date: 2013-06-05 10:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0feca8a93cb3 8015955: ObjectNode.elements should be stronger typed Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java Changeset: 9374c04f38fe Author: attila Date: 2013-06-05 12:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9374c04f38fe 8015961: Several small code-gardening fixes Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java Changeset: 60bc560df392 Author: hannesw Date: 2013-06-05 12:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/60bc560df392 8015350: Array.prototype.reduceRight issue with large length and index Reviewed-by: attila, sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + test/script/basic/JDK-8015350.js + test/script/basic/JDK-8015350.js.EXPECTED Changeset: 35bba63990b7 Author: jlaskey Date: 2013-06-05 10:32 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/35bba63990b7 8015911: $EXEC does not handle large outputs Reviewed-by: sundar, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 16219bef66ec Author: jlaskey Date: 2013-06-05 12:41 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/16219bef66ec 8015910: Nashorn JavaFX includes are out of sync with JavaFX repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/controls.js ! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js ! src/jdk/nashorn/internal/runtime/resources/fx/swt.js ! src/jdk/nashorn/internal/runtime/resources/fx/web.js Changeset: e3bd0ed64da8 Author: jlaskey Date: 2013-06-05 12:54 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e3bd0ed64da8 Merge From martinrb at google.com Wed Jun 5 16:01:47 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 5 Jun 2013 09:01:47 -0700 Subject: 8015963: Add at since tags to new ConcurrentHashMap methods In-Reply-To: <51AF4CBF.30603@oracle.com> References: <51AF162A.6030004@oracle.com> <51AF4CBF.30603@oracle.com> Message-ID: On Wed, Jun 5, 2013 at 7:35 AM, Chris Hegarty wrote: > > On 05/06/2013 14:49, Martin Buchholz wrote: > >> jsr166 CVS updated with this patch, except that the jsr166 style is not >> to introduce a blank line just for @since. >> > > Thanks Martin, > > Trivially, I think you are still missing a few: > > reduceEntriesToLong, reduceEntriesToInt, and class KeySetView. > > Done. --- ConcurrentHashMap.java 5 Jun 2013 13:48:59 -0000 1.220 +++ ConcurrentHashMap.java 5 Jun 2013 15:59:29 -0000 @@ -3962,6 +3962,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * @since 1.8 */ public long reduceEntriesToLong(long parallelismThreshold, ToLongFunction> transformer, @@ -3987,6 +3988,7 @@ * @param reducer a commutative associative combining function * @return the result of accumulating the given transformation * of all entries + * @since 1.8 */ public int reduceEntriesToInt(long parallelismThreshold, ToIntFunction> transformer, @@ -4162,6 +4164,8 @@ * {@link #keySet(Object) keySet(V)}, * {@link #newKeySet() newKeySet()}, * {@link #newKeySet(int) newKeySet(int)}. + * + * @since 1.8 */ public static class KeySetView extends CollectionView implements Set, java.io.Serializable { From brian.burkhalter at oracle.com Wed Jun 5 16:16:18 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2013 09:16:18 -0700 Subject: Measuring performance changes from applying 4837946 patch In-Reply-To: <51AF58B3.2060408@oracle.com> References: <51ADA70F.7040208@oracle.com> <51ADF04E.7060605@oracle.com> <51AF02C4.1050202@oracle.com> <4852D6C7-C0CF-4581-A862-CACBD2A09423@oracle.com> <51AF58B3.2060408@oracle.com> Message-ID: <9DA3C544-8FF8-475F-80AB-B4025EACBCA4@oracle.com> On Jun 5, 2013, at 8:26 AM, Aleksey Shipilev wrote: > Aleksey : Sorry: I had not finished my first coffee yet. > >>> b) the annotations you are using on each method, can flow up to >>> class-level annotation, and will be inherited by all the @GMB methods; >> >> I was not aware of this. > > Yes, and with the daizy-fresh JMH, it is even possible to move the > remaining data upwards to the class level: > http://mail.openjdk.java.net/pipermail/jmh-dev/2013-June/000074.html > >>> c) it is a good idea to initialize the State fields within the @Setup >>> method, because we guarantee correct initialization JMM-wise (try to run >>> your benchmark on non-x86 hardware, and you can occasionally see the >>> NPEs, because genericFactor1/2 might be null; you can also make the same >>> effect with "final" on fields, but that wouldn't be the generic case). >> >> That is good to know also. I read about State Fixtures but did not know >> of this behavior. > > I take that back, the JMH samples are correct. JMH will initialize the > states with the worker threads, and publish it properly for you. You can > keep the init the way you have it now. The only culprit is that if State > is getting reused between the benchmark runs, it is a good idea to > re-initialize it with @Setup. But, since BigIntegers are "immutable", > you don't actually care. Thanks for the further clarifications. Brian From aleksej.efimov at oracle.com Wed Jun 5 16:34:23 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 05 Jun 2013 20:34:23 +0400 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51AF0E6B.3030305@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> <51AE0582.7030909@oracle.com> <51AF0E6B.3030305@oracle.com> Message-ID: <51AF688F.2050106@oracle.com> On 06/05/2013 02:09 PM, Alan Bateman wrote: > On 04/06/2013 16:19, Aleksej Efimov wrote: >> Alan, Jason, >> Thanks for clarification. I have moved the serial data from binary >> files to test class: >> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ >> >> >> -Aleksej >> > Thanks, this looks much better. > > Just a few remaining comments on the test: > > - It needs a copyright header Header added. > > - I think twocauses and normaljdk7ser should have a comment to detail > how the bytes are generated. One idea (and you'll see this in a few > other tests) is to have an option to the test to generate the bytes. > Alternatively put the code in comments so that anyone can re-generate > them if needed. As they are constants then they can be final and > probably should be in uppercase. - Comments with code chunks are added (alternative way). - 'twocauses' and 'normaljdk7ser' made final and uppercase. > > Otherwise I think this is good to go. > > -Alan. New webrev: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.7/ Thanks, -Aleksej From huizhe.wang at oracle.com Wed Jun 5 16:43:04 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Wed, 05 Jun 2013 09:43:04 -0700 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51AF0E6B.3030305@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> <51AE0582.7030909@oracle.com> <51AF0E6B.3030305@oracle.com> Message-ID: <51AF6A98.2070904@oracle.com> Aleksej, When you're ready, after fixing the remaining things as Alan commented, please push the change to hg.openjdk.java.net/jdk8/tl-gate/jaxp. For 7u, send a request to jdk7u-dev and indicate that the changes are identical to that for jdk8. Thanks, Joe On 6/5/2013 3:09 AM, Alan Bateman wrote: > On 04/06/2013 16:19, Aleksej Efimov wrote: >> Alan, Jason, >> Thanks for clarification. I have moved the serial data from binary >> files to test class: >> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/ >> >> >> -Aleksej >> > Thanks, this looks much better. > > Just a few remaining comments on the test: > > - It needs a copyright header > > - I think twocauses and normaljdk7ser should have a comment to detail > how the bytes are generated. One idea (and you'll see this in a few > other tests) is to have an option to the test to generate the bytes. > Alternatively put the code in comments so that anyone can re-generate > them if needed. As they are constants then they can be final and > probably should be in uppercase. > > Otherwise I think this is good to go. > > -Alan. From brian.burkhalter at oracle.com Wed Jun 5 17:26:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2013 10:26:05 -0700 (PDT) Subject: Sponsor needed: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Message-ID: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> The webrev and patch are here http://cr.openjdk.java.net/~bpb/7032154/ And the pertinent recent review in this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017317.html The changeset comment is: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Summary: Performance improvements for double/float -> String and decimal/hex String -> double/float conversions. Reviewed-by: martin Contributed-by: brian.burkhalter at oracle.com The substantial majority of the work for this patch was completed by Sergey Kuksenko a couple of years ago. It was since ported to the current repository tip, a couple of bugs were found and fixed, some refactoring and code and comment cleanup were done, and JML annotations added. Thanks to Dmitry Nadezhin and Olivier Lagneau for helping to verify and improve the changes and to Martin Buchholz and Iris Clark for reviewing them. Thanks, Brian From mandy.chung at oracle.com Wed Jun 5 18:33:14 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 05 Jun 2013 11:33:14 -0700 Subject: Sponsor needed: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> References: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> Message-ID: <51AF846A.30606@oracle.com> I can sponsor it. I haven't got the cycle to review this change but Martin and Iris reviewed it and this changeset is good to go. Mandy On 6/5/2013 10:26 AM, Brian Burkhalter wrote: > The webrev and patch are here > > http://cr.openjdk.java.net/~bpb/7032154/ > > And the pertinent recent review in this thread > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017317.html > > The changeset comment is: > > 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal > Summary: Performance improvements for double/float -> String and decimal/hex String -> double/float conversions. > Reviewed-by: martin > Contributed-by: brian.burkhalter at oracle.com > > The substantial majority of the work for this patch was completed by Sergey Kuksenko a couple of years ago. It was since ported to the current repository tip, a couple of bugs were found and fixed, some refactoring and code and comment cleanup were done, and JML annotations added. Thanks to Dmitry Nadezhin and Olivier Lagneau for helping to verify and improve the changes and to Martin Buchholz and Iris Clark for reviewing them. > > Thanks, > > Brian From martinrb at google.com Wed Jun 5 18:54:06 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 5 Jun 2013 11:54:06 -0700 Subject: Sponsor needed: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> References: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> Message-ID: You could add more contributors to the Contributed-by: line. On Wed, Jun 5, 2013 at 10:26 AM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > The changeset comment is: > > 7032154: Performance tuning of > sun.misc.FloatingDecimal/FormattedFloatingDecimal > Summary: Performance improvements for double/float -> String and > decimal/hex String -> double/float conversions. > Reviewed-by: martin > Contributed-by: brian.burkhalter at oracle.com > > The substantial majority of the work for this patch was completed by > Sergey Kuksenko a couple of years ago. It was since ported to the current > repository tip, a couple of bugs were found and fixed, some refactoring and > code and comment cleanup were done, and JML annotations added. Thanks to > Dmitry Nadezhin and Olivier Lagneau for helping to verify and improve the > changes and to Martin Buchholz and Iris Clark for reviewing them. > > Thanks, > > Brian From brian.burkhalter at oracle.com Wed Jun 5 18:56:39 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 5 Jun 2013 11:56:39 -0700 Subject: Sponsor needed: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal In-Reply-To: References: <6834622E-3EC6-4358-B199-AB45DAEE7F09@oracle.com> Message-ID: <7CFD78FE-758E-4809-AA59-53F7825D4F60@oracle.com> Will do. On Jun 5, 2013, at 11:54 AM, Martin Buchholz wrote: > You could add more contributors to the Contributed-by: line. From Alan.Bateman at oracle.com Wed Jun 5 20:19:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Jun 2013 21:19:36 +0100 Subject: RFR 8009581: Xpathexception does not honor initcause() In-Reply-To: <51AF688F.2050106@oracle.com> References: <5177E3C4.3090703@oracle.com>> <> <517821CB.70608@oracle.com>> <> <> <> <<517E7982.8060803@oracle.com>> <> <517F6DDB.4020809@oracle.com>> <> <> <> <<518E9F55.6030603@oracle.com>> <> <5196864B.1040003@oracle.com>> <> <> <> <> <> <> <> <> <> <519B5444.7060701@oracle.com>> <> <> <> > <> <> <> <519EEBE2.6070409@oracle.com> <51A0784F.8090800@oracle.com>> <> <<51A0DBBE.2060501@oracle.com> <51A2CBAD.7000307@oracle.com>> <> <> <> <51A49D6B.3020407@oracle.com>> <> > <> <> <> <51A55C70.4070403@oracle.com>> <> > <> <51A8A813.9070903@oracle.com> <51A8B1B1.60108@oracle.com>> <<51ACA5AB.5050606@oracle.com> <51ADF256.2090303@oracle.com> <51AE0582.7030909@oracle.com> <51AF0E6B.3030305@oracle.com> <51AF688F.2050106@oracle.com> Message-ID: <51AF9D58.8030404@oracle.com> On 05/06/2013 17:34, Aleksej Efimov wrote: > New webrev: > http://cr.openjdk.java.net/~dmeetry/8009581/webrev.7/ > Thanks, you've addressed all the issues so I think we are good now. -Alan From mike.duigou at oracle.com Wed Jun 5 20:41:11 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Jun 2013 13:41:11 -0700 Subject: RFR 8015895 Int/LongStream.range/rangeClosed In-Reply-To: References: Message-ID: Looks good to me. Mike On Jun 5 2013, at 06:10 , Paul Sandoz wrote: > Hi, > > The following was decided by the JSR-335 EG: > > 1) Int/LongStream.range are restricted to a fixed step of 1. The map operation can be used to adjust the step. > > 2) Int/LongStream.rangeClosed methods were added for a closed range with a fixed step of 1, in addition to the half open range of 1). > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015895-rangeClosed/webrev/ > > > The range spliterator implementations also have some biasing of the splits for large ranges, since the larger the range the more likely it will be used in conjunction with limit or another form of short-circuiting operation. This was intentionally kept simple for the moment: a ratio of 1:7 in size for left:right when the size is > 2^24. > > > There is some code commented out in the implementation and tests which will be uncommented once Stream concatenation makes it's way into TL. I wanted to get this in sooner rather than be blocked waiting on concatenation. Stream concatenation will be used in LongStream for edge cases when the range is > Long.MAX_VALUE e.g. LongStream.range(Long.MIN_VALUE, Long.MAX_VALUE), LongStream.rangeClosed(0, Long.MAX_VALUE). > > > This webrev is layered on top of: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015492-rm-DoubleStream.range/webrev/ > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015798-asXxxStream/webrev/ > > Paul. From david.holmes at oracle.com Thu Jun 6 09:32:57 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 06 Jun 2013 09:32:57 +0000 Subject: hg: jdk8/tl/jdk: 8015470: Remove redundant calls of toString() on String objects Message-ID: <20130606093321.BBDDF48FED@hg.openjdk.java.net> Changeset: 571e5f452640 Author: dholmes Date: 2013-06-06 05:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/571e5f452640 8015470: Remove redundant calls of toString() on String objects Reviewed-by: dholmes, alanb Contributed-by: Otavio Goncalves ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/java/lang/annotation/IncompleteAnnotationException.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/tools/java/MemberDefinition.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java From aleksey.shipilev at oracle.com Thu Jun 6 09:38:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 06 Jun 2013 13:38:04 +0400 Subject: Backport CR 7132378: fix for FutureTask.set() race Message-ID: <51B0587C.5040100@oracle.com> Hi guys, What is the process to back port the issue to 7u? Specifically, I think we need to have this issue backported: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 -Aleksey. From weijun.wang at oracle.com Thu Jun 6 09:42:53 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 06 Jun 2013 17:42:53 +0800 Subject: Is there a better way to throw this exception? Message-ID: <51B0599D.4020906@oracle.com> Hi All I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: void once() throws One, Two Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *all* fails. Now it looks like void multiple() throws One, Two { Exception saved = null; for (all chances) { try { once(); return; } catch (Exception e) { if (saved != null) saved = e; } } if (saved instanceof One) { throw (One)saved; } else if (saved instanceof One) { throw (Two)saved; } else if (saved instanceof RuntimeException) { throw (RuntimeException)saved; } else { // Not likely, but I've already wrote so many lines. throw new RuntimeException(saved); } } Is there any way I can make it shorter? Thanks Max From chris.hegarty at oracle.com Thu Jun 6 09:43:27 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Jun 2013 10:43:27 +0100 Subject: Backport CR 7132378: fix for FutureTask.set() race In-Reply-To: <51B0587C.5040100@oracle.com> References: <51B0587C.5040100@oracle.com> Message-ID: <51B059BF.9080503@oracle.com> If the changeset applies cleanly to 7u-dev, then its a simple approval request [1]. -Chris. [1] http://openjdk.java.net/projects/jdk7u/approval-template.html On 06/06/2013 10:38 AM, Aleksey Shipilev wrote: > Hi guys, > > What is the process to back port the issue to 7u? > > Specifically, I think we need to have this issue backported: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 > > -Aleksey. > From Alan.Bateman at oracle.com Thu Jun 6 09:44:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Jun 2013 10:44:16 +0100 Subject: Backport CR 7132378: fix for FutureTask.set() race In-Reply-To: <51B0587C.5040100@oracle.com> References: <51B0587C.5040100@oracle.com> Message-ID: <51B059F0.1050209@oracle.com> On 06/06/2013 10:38, Aleksey Shipilev wrote: > Hi guys, > > What is the process to back port the issue to 7u? > > Specifically, I think we need to have this issue backported: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 > > -Aleksey. The process is on the jdk7u project page [1]. As this one is in jdk8 for some time then it should be just a matter of mailing jdk7u-dev to ask for approval (and a sponsor). I would suggest moving on it quickly because jdk7u-dev will be forked soon to create the stabilization forest for 7u40. -Alan. [1] http://openjdk.java.net/projects/jdk7u/ From aleksey.shipilev at oracle.com Thu Jun 6 09:45:21 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 06 Jun 2013 13:45:21 +0400 Subject: Backport CR 7132378: fix for FutureTask.set() race In-Reply-To: <51B059F0.1050209@oracle.com> References: <51B0587C.5040100@oracle.com> <51B059F0.1050209@oracle.com> Message-ID: <51B05A31.4000805@oracle.com> On 06/06/2013 01:44 PM, Alan Bateman wrote: > On 06/06/2013 10:38, Aleksey Shipilev wrote: >> Hi guys, >> >> What is the process to back port the issue to 7u? >> >> Specifically, I think we need to have this issue backported: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 >> >> -Aleksey. > > The process is on the jdk7u project page [1]. As this one is in jdk8 for > some time then it should be just a matter of mailing jdk7u-dev to ask > for approval (and a sponsor). I would suggest moving on it quickly > because jdk7u-dev will be forked soon to create the stabilization forest > for 7u40. Thanks Alan and Chris, I'll send to the note to jdk7u on this. -Aleksey. From Alan.Bateman at oracle.com Thu Jun 6 12:02:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Jun 2013 05:02:06 -0700 (PDT) Subject: RFR (jaxp): JDK-8013434: Xalan and Xerces internal ObjectFactory need rework In-Reply-To: <51ACCA3A.9040006@oracle.com> References: <51ACCA3A.9040006@oracle.com> Message-ID: <51B07A3E.90706@oracle.com> On 03/06/2013 17:54, Daniel Fuchs wrote: > Hi, > > In order to prepare for modularization, we need to review all > the places where META-INF/services is parsed directly. > : > > > I've skimmed over the changes and it looks good to me (might be awkward if we upgrade to new versions of Xerces or Xalan but I think that is a bigger issue). -Alan. From Alan.Bateman at oracle.com Thu Jun 6 12:09:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Jun 2013 13:09:16 +0100 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package In-Reply-To: <51AEF52C.7020301@oracle.com> References: <51AE70BC.3050305@oracle.com> <51AED898.9010104@oracle.com> <51AEF52C.7020301@oracle.com> Message-ID: <51B07BEC.3050301@oracle.com> On 05/06/2013 09:22, Se?n Coffey wrote: > > There are plans to introduce a more robust testcase to test all > restricted packages. Hope to have that brought into jdk8 in coming > weeks. Good points on the @summary text. Meant to update that. Test > now checks package definition : > > http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8.2/ > > This looks good to me. -Alan. From chris.hegarty at oracle.com Thu Jun 6 12:34:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Jun 2013 13:34:08 +0100 Subject: RFR: 8000450: Restrict access to com/sun/corba/se/impl package In-Reply-To: <51B07BEC.3050301@oracle.com> References: <51AE70BC.3050305@oracle.com> <51AED898.9010104@oracle.com> <51AEF52C.7020301@oracle.com> <51B07BEC.3050301@oracle.com> Message-ID: <51B081C0.7080108@oracle.com> On 06/06/2013 01:09 PM, Alan Bateman wrote: > On 05/06/2013 09:22, Se?n Coffey wrote: >> >> There are plans to introduce a more robust testcase to test all >> restricted packages. Hope to have that brought into jdk8 in coming >> weeks. Good points on the @summary text. Meant to update that. Test >> now checks package definition : >> >> http://cr.openjdk.java.net/~coffeys/webrev.8000450.jdk8.2/ >> >> > This looks good to me. +1 -Chris. > > -Alan. > From chris.hegarty at oracle.com Thu Jun 6 12:38:57 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Jun 2013 13:38:57 +0100 Subject: RFR 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator In-Reply-To: References: Message-ID: <51B082E1.90107@oracle.com> The changes look fine to me Paul. Strangely, the webrev seems to indicate mercurial history of other bugs, but I don't see any evidence of them. Maybe an issue with webrev and mq? -Chris. On 06/03/2013 05:09 PM, Paul Sandoz wrote: > Hi, > > The following patch renames the Spliterators.spliteratorFromIterator methods to Spliterators.iterator, which is more consistent with other methods on the class: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015792-Spliterators.iterator/webrev/ > > CCC is in progress. > > Paul. > From paul.sandoz at oracle.com Thu Jun 6 12:48:45 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 6 Jun 2013 14:48:45 +0200 Subject: RFR 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator In-Reply-To: <51B082E1.90107@oracle.com> References: <51B082E1.90107@oracle.com> Message-ID: <5EC2019B-984A-4252-B32C-F64FBAB638B9@oracle.com> On Jun 6, 2013, at 2:38 PM, Chris Hegarty wrote: > The changes look fine to me Paul. > Thanks. > Strangely, the webrev seems to indicate mercurial history of other bugs, but I don't see any evidence of them. Maybe an issue with webrev and mq? > I don't think it an issue. There are patches in my queue that precede this patch. Webrev script is declaring preceding patch revisions in my queue for patches that modify the same file. Paul. From eric.mccorkle at oracle.com Thu Jun 6 12:49:34 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 06 Jun 2013 12:49:34 +0000 Subject: hg: jdk8/tl/langtools: 8015701: MethodParameters are not filled in for synthetic captured local variables Message-ID: <20130606124940.E621C48FF6@hg.openjdk.java.net> Changeset: 8717586f7b05 Author: emc Date: 2013-06-06 08:48 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8717586f7b05 8015701: MethodParameters are not filled in for synthetic captured local variables Summary: Synthetic parameters for captured local variables in an anonymous inner class are not added to MethodParameters attributes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/8015701/AnonymousParameters.java From eric.mccorkle at oracle.com Thu Jun 6 13:07:57 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 06 Jun 2013 09:07:57 -0400 Subject: JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK Message-ID: <51B089AD.5080101@oracle.com> Hello, Please review this simple patch that removes setProtectionDomain0 from java.lang.Class. This is part of a two-stage process to remove the function from the JVM as well. This method is not used, and has not been used in some time (at least before 1.5) The webrev is here: http://cr.openjdk.java.net/~emc/8016019/ The change request ih here: http://bugs.sun.com/view_bug.do?bug_id=8016019 Thanks, Eric From Alan.Bateman at oracle.com Thu Jun 6 13:22:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Jun 2013 06:22:14 -0700 (PDT) Subject: JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK In-Reply-To: <51B089AD.5080101@oracle.com> References: <51B089AD.5080101@oracle.com> Message-ID: <51B08D06.3020103@oracle.com> On 06/06/2013 14:07, Eric McCorkle wrote: > Hello, > > Please review this simple patch that removes setProtectionDomain0 from > java.lang.Class. This is part of a two-stage process to remove the > function from the JVM as well. > > This method is not used, and has not been used in some time (at least > before 1.5) > > The webrev is here: > http://cr.openjdk.java.net/~emc/8016019/ > > The change request ih here: > http://bugs.sun.com/view_bug.do?bug_id=8016019 > > Thanks, > Eric This looks fine to me, I don't see any usages. -Alan. From sean.coffey at oracle.com Thu Jun 6 13:26:36 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 06 Jun 2013 13:26:36 +0000 Subject: hg: jdk8/tl/jdk: 8000450: Restrict access to com/sun/corba/se/impl package Message-ID: <20130606132710.9931348FFA@hg.openjdk.java.net> Changeset: c4480e0d9f53 Author: coffeys Date: 2013-06-06 14:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4480e0d9f53 8000450: Restrict access to com/sun/corba/se/impl package Reviewed-by: alanb, chegar, lancea ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java From eric.mccorkle at oracle.com Thu Jun 6 13:53:01 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 06 Jun 2013 13:53:01 +0000 Subject: hg: jdk8/tl/jdk: 8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK Message-ID: <20130606135324.4914448FFD@hg.openjdk.java.net> Changeset: 37aa82c52317 Author: emc Date: 2013-06-06 09:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37aa82c52317 8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK Summary: setProtectionDomain0 and JVM_SetProtectionDomain are unused since at least 1.5. This is the JDK side of a changeset to remove it. Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c From eric.mccorkle at oracle.com Thu Jun 6 13:55:23 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 06 Jun 2013 09:55:23 -0400 Subject: JDK-8016019: Remove setProtectionDomain0 and JVM_SetProtectionDomain in JDK In-Reply-To: <51B08D06.3020103@oracle.com> References: <51B089AD.5080101@oracle.com> <51B08D06.3020103@oracle.com> Message-ID: <51B094CB.20600@oracle.com> Thanks, Alan. On 06/06/13 09:22, Alan Bateman wrote: > On 06/06/2013 14:07, Eric McCorkle wrote: >> Hello, >> >> Please review this simple patch that removes setProtectionDomain0 from >> java.lang.Class. This is part of a two-stage process to remove the >> function from the JVM as well. >> >> This method is not used, and has not been used in some time (at least >> before 1.5) >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8016019/ >> >> The change request ih here: >> http://bugs.sun.com/view_bug.do?bug_id=8016019 >> >> Thanks, >> Eric > This looks fine to me, I don't see any usages. > > -Alan. From maurizio.cimadamore at oracle.com Thu Jun 6 14:39:23 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 06 Jun 2013 14:39:23 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130606143959.C98A148001@hg.openjdk.java.net> Changeset: 6e30a513c945 Author: mcimadamore Date: 2013-06-06 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e30a513c945 6360970: javac erroneously accept ambiguous field reference Summary: clash between ambiguous fields in superinterface and unambiguous field in subinterface is erroneously marked as unambiguous Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/6360970/T6360970.java + test/tools/javac/6360970/T6360970.out Changeset: 7889d1fe2597 Author: mcimadamore Date: 2013-06-06 15:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7889d1fe2597 7139681: Enhanced for loop: local variable scope inconsistent with JLS Summary: For-each loop variable is incorrectly visible from the for-each expression Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/foreach/7139681/T7139681neg.java + test/tools/javac/foreach/7139681/T7139681neg.out + test/tools/javac/foreach/7139681/T7139681pos.java Changeset: 349160289ba2 Author: mcimadamore Date: 2013-06-06 15:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/349160289ba2 8008627: Compiler mishandles three-way return-type-substitutability Summary: Compiler should not enforce an order in how ambiguous methods should be resolved Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/rawOverride/T8008627.java ! test/tools/javac/lambda/funcInterfaces/NonSAM2.java ! test/tools/javac/lambda/funcInterfaces/NonSAM2.out Changeset: f8472e561a97 Author: mcimadamore Date: 2013-06-06 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f8472e561a97 8015432: javac crashes with stack overflow when method called recursively from nested generic call Summary: Check.checkMethod should only be called after inference has completed Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/inference/7177306/T7177306a.out + test/tools/javac/lambda/TargetType74.java Changeset: f218bb5ebd53 Author: mcimadamore Date: 2013-06-06 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f218bb5ebd53 8015648: Duplicate variable in lambda causes javac crash Summary: Missing flag in synthetic lambda blog is causing duplicates symbol to go undetected Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/LambdaScope05.java + test/tools/javac/lambda/LambdaScope05.out Changeset: 5b039297151e Author: mcimadamore Date: 2013-06-06 15:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5b039297151e Merge From peter.levart at gmail.com Thu Jun 6 14:57:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 06 Jun 2013 16:57:12 +0200 Subject: Is there a better way to throw this exception? In-Reply-To: <51B0599D.4020906@oracle.com> References: <51B0599D.4020906@oracle.com> Message-ID: <51B0A348.70805@gmail.com> On 06/06/2013 11:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and > possibly other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and > want to throw the first exception if *all* fails. Now it looks like > > void multiple() throws One, Two { > Exception saved = null; > for (all chances) { > try { > once(); > return; > } catch (Exception e) { > if (saved != null) saved = e; > } > } > if (saved instanceof One) { > throw (One)saved; > } else if (saved instanceof One) { > throw (Two)saved; > } else if (saved instanceof RuntimeException) { > throw (RuntimeException)saved; > } else { > // Not likely, but I've already wrote so many lines. > throw new RuntimeException(saved); > } > } > > Is there any way I can make it shorter? Hi Max, If you don't mind re-throwing the last exception thrown instead of the first and you can transform your for loop into a while loop, for example: void multiple() throws One, Two { int tries = 10; int i = 0; while (true) { try { once(); return; } catch (Exception e) { if (++i >= tries) { throw e; } } } } ...otherwise you can re-throw the first exception if you can extract the first loop iteration out of the loop: void multiple() throws One, Two { try { once(); // first chance return; } catch (Exception e) { for (rest of chances) { try { once(); return; } catch (Exception ignore) {} } throw e; } } Regards, Peter > > Thanks > Max From stevenschlansker at gmail.com Thu Jun 6 15:35:56 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Thu, 6 Jun 2013 08:35:56 -0700 Subject: Is there a better way to throw this exception? In-Reply-To: <51B0599D.4020906@oracle.com> References: <51B0599D.4020906@oracle.com> Message-ID: On Jun 6, 2013, at 2:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *all* fails. Now it looks like > > void multiple() throws One, Two { > Exception saved = null; > for (all chances) { > try { > once(); > return; > } catch (Exception e) { > if (saved != null) saved = e; > } > } > if (saved instanceof One) { > throw (One)saved; > } else if (saved instanceof One) { > throw (Two)saved; > } else if (saved instanceof RuntimeException) { > throw (RuntimeException)saved; > } else { > // Not likely, but I've already wrote so many lines. > throw new RuntimeException(saved); > } > } > > Is there any way I can make it shorter? If you use / are willing to use Guava, you can replace all of the exception if clauses with: void multiple() throws One, Two { for (?) { ? } Throwables.propagateIfPossible(saved, One.class, Two.class); throw Throwables.propagate(saved); } http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Throwables.html#propagateIfPossible(java.lang.Throwable,%20java.lang.Class,%20java.lang.Class) From aleksej.efimov at oracle.com Thu Jun 6 17:10:37 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Thu, 06 Jun 2013 21:10:37 +0400 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" Message-ID: <51B0C28D.7080100@oracle.com> Hi, The expression "string(-0.0)" incorrectly transformed to -0, but it should be 0 according to W3C specification: http://www.w3.org/TR/xpath/#function-string The webrev with fix and the test case: http://cr.openjdk.java.net/~dmeetry/8015978/webrev.1/ There is another way of disabling the -0 result. In current webrev the minus zero is processed with such code: + + //Check for -0.0 and convert it to 0.0 + if (new Double(d).equals(new Double(-0.0)) + d=0.0; We can make the replace of -0 -> 0 faster (I think but didn't tested it) with the following code, but it looks strange and will work both for 0 and -0: + //Check for -0.0 and convert it to 0.0 + if (d == 0.0) + d=0.0; -Aleksej From dmitry.degrave at oracle.com Thu Jun 6 17:29:31 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 06 Jun 2013 17:29:31 +0000 Subject: hg: jdk8/tl/jaxp: 8009579: Xpathexception does not honor initcause() Message-ID: <20130606172939.D99A348019@hg.openjdk.java.net> Changeset: 7d14fea1e893 Author: dmeetry Date: 2013-06-06 20:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7d14fea1e893 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efimov at oracle.com ! src/javax/xml/xpath/XPathException.java From dmitry.degrave at oracle.com Thu Jun 6 17:30:49 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 06 Jun 2013 17:30:49 +0000 Subject: hg: jdk8/tl/jdk: 8009579: Xpathexception does not honor initcause() Message-ID: <20130606173141.EC1AD4801B@hg.openjdk.java.net> Changeset: e6d2c605930c Author: dmeetry Date: 2013-06-06 20:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6d2c605930c 8009579: Xpathexception does not honor initcause() Reviewed-by: alanb, dholmes, joehw Contributed-by: aleksej.efimov at oracle.com + test/javax/xml/jaxp/XPath/8009579/XPathExceptionInitCause.java From rob.mckenna at oracle.com Thu Jun 6 18:04:40 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 06 Jun 2013 19:04:40 +0100 Subject: RFR: 8016063 - getFinalAttributes should use FindClose Message-ID: <51B0CF38.4060009@oracle.com> Hi folks, When fixing 7038105 I overlooked the fact I should have use FindClose instead of CloseHandle after calling FindFirstFileW: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx http://cr.openjdk.java.net/~robm/8016063/webrev.01/ Thanks, -Rob From Alan.Bateman at oracle.com Thu Jun 6 18:17:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Jun 2013 19:17:53 +0100 Subject: RFR: 8016063 - getFinalAttributes should use FindClose In-Reply-To: <51B0CF38.4060009@oracle.com> References: <51B0CF38.4060009@oracle.com> Message-ID: <51B0D251.4070003@oracle.com> On 06/06/2013 19:04, Rob McKenna wrote: > Hi folks, > > When fixing 7038105 I overlooked the fact I should have use FindClose > instead of CloseHandle after calling FindFirstFileW: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418%28v=vs.85%29.aspx > > > http://cr.openjdk.java.net/~robm/8016063/webrev.01/ > > Thanks, > > -Rob Looks fine, sorry I missed that too during the review. -Alan. From daniel.fuchs at oracle.com Thu Jun 6 18:47:43 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Thu, 06 Jun 2013 18:47:43 +0000 Subject: hg: jdk8/tl/jaxp: 8013434: Xalan and Xerces internal ObjectFactory need rework Message-ID: <20130606184750.788B24801C@hg.openjdk.java.net> Changeset: e93beba07830 Author: dfuchs Date: 2013-06-06 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e93beba07830 8013434: Xalan and Xerces internal ObjectFactory need rework Summary: With this changeset, DTMManager and XSLTCDTMManager will always use their own default implementation. Reviewed-by: joehw, alanb - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory - src/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory - src/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager ! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Transform.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java ! src/com/sun/org/apache/xalan/internal/xsltc/dom/XSLTCDTMManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java ! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java ! src/com/sun/org/apache/xpath/internal/XPathContext.java From mike.duigou at oracle.com Thu Jun 6 18:53:57 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 06 Jun 2013 18:53:57 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130606185451.703374801D@hg.openjdk.java.net> Changeset: 69d566198fe4 Author: henryjen Date: 2013-06-05 15:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69d566198fe4 8015522: CharSequence.codePoints can be faster Reviewed-by: martin, psandoz, alanb Contributed-by: henry.jen at oracle.com ! src/share/classes/java/lang/CharSequence.java Changeset: 26922bad9c08 Author: mduigou Date: 2013-06-06 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26922bad9c08 Merge From Lance.Andersen at oracle.com Thu Jun 6 20:09:46 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 6 Jun 2013 13:09:46 -0700 (PDT) Subject: Review request for 8016101, javadoc typos for SerialRef and SerialStruct Message-ID: Hi, Need a reviewer for this minor javadoc update for bug 8016101 SerialStruct was missing a javadoc @param tag in the constructor SerialRef had an extra '.' Best Lance hg diff diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java --- a/src/share/classes/javax/sql/rowset/serial/SerialRef.java Tue May 28 15:22:30 2013 +0200 +++ b/src/share/classes/javax/sql/rowset/serial/SerialRef.java Thu Jun 06 16:01:07 2013 -0400 @@ -202,7 +202,7 @@ } /** - * Returns a clone of this {@code SerialRef}. . + * Returns a clone of this {@code SerialRef}. * The underlying {@code Ref} object will be set to null. * * @return a clone of this SerialRef diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialStruct.java --- a/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Tue May 28 15:22:30 2013 +0200 +++ b/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Thu Jun 06 16:01:07 2013 -0400 @@ -87,6 +87,7 @@ * object for custom mapping the SQL structured type or any of its * attributes that are SQL structured types. * + * @param in an instance of {@code Struct} Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From r.spilker at gmail.com Tue Jun 4 14:16:01 2013 From: r.spilker at gmail.com (Roel Spilker) Date: Tue, 4 Jun 2013 16:16:01 +0200 Subject: hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: <20130603154340.F1AC048EE8@hg.openjdk.java.net> References: <20130603154340.F1AC048EE8@hg.openjdk.java.net> Message-ID: Looking at the implementation, the code in toString suggest that it's worthwhile to optimize for an empty suffix (although I doubt that this optimization has any measurable effects). But the constructor always concatenates the prefix and the suffix, which results in both a new string instance and a StringBuilder. If an empty suffix is common (actually, having a separate constructor and the current toString implementation both suggest it is), I think that the initializing the emptyValue field in the constructor should be written as: this.emptyValue = this.suffix.isEmpty() ? this.prefix : this.prefix + this.suffix; Actually, since there is also a setEmptyValue, I think that the field should be left null, and toString and length check for null, resulting in even less objects allocated in that scenario. Roel On Mon, Jun 3, 2013 at 5:43 PM, wrote: > Changeset: a79e2683eae3 > Author: psandoz > Date: 2013-06-03 17:37 +0200 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79e2683eae3 > > 8014383: StringJoiner example in class description not in sync with > streams API > Reviewed-by: alanb > > ! src/share/classes/java/util/StringJoiner.java > > From steven at likeness.com Thu Jun 6 15:43:14 2013 From: steven at likeness.com (Steven Schlansker) Date: Thu, 6 Jun 2013 08:43:14 -0700 Subject: Is there a better way to throw this exception? In-Reply-To: <51B0599D.4020906@oracle.com> References: <51B0599D.4020906@oracle.com> Message-ID: On Jun 6, 2013, at 2:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *all* fails. Now it looks like > > void multiple() throws One, Two { > Exception saved = null; > for (all chances) { > try { > once(); > return; > } catch (Exception e) { > if (saved != null) saved = e; > } > } > if (saved instanceof One) { > throw (One)saved; > } else if (saved instanceof One) { > throw (Two)saved; > } else if (saved instanceof RuntimeException) { > throw (RuntimeException)saved; > } else { > // Not likely, but I've already wrote so many lines. > throw new RuntimeException(saved); > } > } If you use / are willing to use Guava, you can replace all of the exception if clauses with: void multiple() throws One, Two { for (?) { ? } Throwables.propagateIfPossible(saved, One.class, Two.class); throw Throwables.propagate(saved); } http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Throwables.html#propagateIfPossible(java.lang.Throwable,%20java.lang.Class,%20java.lang.Class) From Lance.Andersen at oracle.com Thu Jun 6 20:41:52 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 6 Jun 2013 16:41:52 -0400 Subject: Review request for 8016101, javadoc typos for SerialRef and SerialStruct In-Reply-To: <51B0F252.4030504@oracle.com> References: <51B0F252.4030504@oracle.com> Message-ID: Hi Aleksey, The change is 2 lines, not worth a webrev. Here it is again in case it was truncated in last email (looked OK on my end) new-host-2:serial lanceandersen$ hg diff diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java --- a/src/share/classes/javax/sql/rowset/serial/SerialRef.java Tue May 28 15:22:30 2013 +0200 +++ b/src/share/classes/javax/sql/rowset/serial/SerialRef.java Thu Jun 06 16:01:07 2013 -0400 @@ -202,7 +202,7 @@ } /** - * Returns a clone of this {@code SerialRef}. . + * Returns a clone of this {@code SerialRef}. * The underlying {@code Ref} object will be set to null. * * @return a clone of this SerialRef diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialStruct.java --- a/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Tue May 28 15:22:30 2013 +0200 +++ b/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Thu Jun 06 16:01:07 2013 -0400 @@ -87,6 +87,7 @@ * object for custom mapping the SQL structured type or any of its * attributes that are SQL structured types. * + * @param in an instance of {@code Struct} * @param map a java.util.Map object in which * each entry consists of 1) a String object * giving the fully qualified name of a UDT and 2) the On Jun 6, 2013, at 4:34 PM, Aleksey Shipilev wrote: > Hi Lance, > > On 06/07/2013 12:09 AM, Lance Andersen - Oracle wrote: >> Need a reviewer for this minor javadoc update for bug 8016101 > > (not a reviewer) The patch appears to be truncated, can you submit it as > patch/webrev somewhere on the web (e.g. cr.openjdk.java.net)? > > -Aleksey. > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Thu Jun 6 20:57:48 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 06 Jun 2013 20:57:48 +0000 Subject: hg: jdk8/tl/jdk: 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Message-ID: <20130606205815.24AEB48021@hg.openjdk.java.net> Changeset: 986793409b2b Author: bpb Date: 2013-06-05 21:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/986793409b2b 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal Summary: Performance improvements for double/float -> String and decimal/hex String -> double/float conversions. Reviewed-by: martin, iris Contributed-by: Sergey Kuksenko , Brian Burkhalter , Dmitry Nadezhin , Olivier Lagneau ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/util/Formatter.java - src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java + test/sun/misc/FloatingDecimal/OldFDBigIntForTest.java + test/sun/misc/FloatingDecimal/OldFloatingDecimalForTest.java + test/sun/misc/FloatingDecimal/TestFDBigInteger.java + test/sun/misc/FloatingDecimal/TestFloatingDecimal.java From rob.mckenna at oracle.com Thu Jun 6 21:21:08 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 06 Jun 2013 21:21:08 +0000 Subject: hg: jdk8/tl/jdk: 8016063: getFinalAttributes should use FindClose Message-ID: <20130606212129.CA1CB48027@hg.openjdk.java.net> Changeset: d28f802ce914 Author: robm Date: 2013-06-06 22:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d28f802ce914 8016063: getFinalAttributes should use FindClose Reviewed-by: alanb ! src/windows/native/java/io/WinNTFileSystem_md.c From huizhe.wang at oracle.com Thu Jun 6 21:42:15 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 06 Jun 2013 14:42:15 -0700 Subject: RFR (jaxp): 8015016: Improve JAXP 1.5 error message Message-ID: <51B10237.5030709@oracle.com> This is a quick fix to improve the error message so that it's clearly differentiated from those reported by the Security Manager. The change is identical for both JDK7 and 8. I will backport the fix to 7u40 if approved. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/ Thanks, Joe From Lance.Andersen at oracle.com Thu Jun 6 21:51:38 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 6 Jun 2013 17:51:38 -0400 Subject: RFR (jaxp): 8015016: Improve JAXP 1.5 error message In-Reply-To: <51B10237.5030709@oracle.com> References: <51B10237.5030709@oracle.com> Message-ID: <3F1ACD1C-C3B4-4533-AFF8-CA7E29CC0AAB@oracle.com> Hi Joe, The change looks OK. I know the messages have to be translated by the globalization team for the other languages. Best Lance On Jun 6, 2013, at 5:42 PM, huizhe wang wrote: > This is a quick fix to improve the error message so that it's clearly differentiated from those reported by the Security Manager. > > The change is identical for both JDK7 and 8. I will backport the fix to 7u40 if approved. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/ > > Thanks, > Joe -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Thu Jun 6 21:56:29 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 6 Jun 2013 14:56:29 -0700 (PDT) Subject: RFR (jaxp): 8015016: Improve JAXP 1.5 error message In-Reply-To: <3F1ACD1C-C3B4-4533-AFF8-CA7E29CC0AAB@oracle.com> References: <51B10237.5030709@oracle.com> <3F1ACD1C-C3B4-4533-AFF8-CA7E29CC0AAB@oracle.com> Message-ID: <51B1058D.2000502@oracle.com> Hi Lance, Thanks for the quick review! I filed a request (8005454) to translate new error messages accumulated since the last translation. But the way the localization tool works is that the error message has to be in the repository before the tool can pull them out. Best, Joe On 6/6/2013 2:51 PM, Lance Andersen - Oracle wrote: > Hi Joe, > > The change looks OK. I know the messages have to be translated by the globalization team for the other languages. > > Best > Lance > On Jun 6, 2013, at 5:42 PM, huizhe wang wrote: > >> This is a quick fix to improve the error message so that it's clearly differentiated from those reported by the Security Manager. >> >> The change is identical for both JDK7 and 8. I will backport the fix to 7u40 if approved. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/ >> >> Thanks, >> Joe > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Lance.Andersen at oracle.com Thu Jun 6 21:58:00 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 6 Jun 2013 14:58:00 -0700 (PDT) Subject: RFR (jaxp): 8015016: Improve JAXP 1.5 error message In-Reply-To: <51B1058D.2000502@oracle.com> References: <51B10237.5030709@oracle.com> <3F1ACD1C-C3B4-4533-AFF8-CA7E29CC0AAB@oracle.com> <51B1058D.2000502@oracle.com> Message-ID: Hi Joe On Jun 6, 2013, at 5:56 PM, huizhe wang wrote: > Hi Lance, > > Thanks for the quick review! > > I filed a request (8005454) to translate new error messages accumulated since the last translation. But the way the localization tool works is that the error message has to be in the repository before the tool can pull them out. > I know it takes time, to get that done. Thank you for clarifying the error message. Best Lance > Best, > Joe > > On 6/6/2013 2:51 PM, Lance Andersen - Oracle wrote: >> Hi Joe, >> >> The change looks OK. I know the messages have to be translated by the globalization team for the other languages. >> >> Best >> Lance >> On Jun 6, 2013, at 5:42 PM, huizhe wang wrote: >> >>> This is a quick fix to improve the error message so that it's clearly differentiated from those reported by the Security Manager. >>> >>> The change is identical for both JDK7 and 8. I will backport the fix to 7u40 if approved. >>> >>> webrev: >>> http://cr.openjdk.java.net/~joehw/jdk8/8015016/webrev/ >>> >>> Thanks, >>> Joe >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Thu Jun 6 22:04:26 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 06 Jun 2013 22:04:26 +0000 Subject: hg: jdk8/tl/jaxp: 8015016: Improve JAXP 1.5 error message Message-ID: <20130606220431.05D2D48028@hg.openjdk.java.net> Changeset: c2957e596bee Author: joehw Date: 2013-06-06 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c2957e596bee 8015016: Improve JAXP 1.5 error message Reviewed-by: lancea ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties From xueming.shen at oracle.com Thu Jun 6 23:03:03 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 6 Jun 2013 16:03:03 -0700 (PDT) Subject: RFR JDK-8015728: (zipfs) demo/zipfs/basic.sh failing Message-ID: <51B11527.6040607@oracle.com> Hi, Please help review the proposed change to fix the regression triggered by the change for #6303183, in which the change failed to update the written loc entry size correctly when the "NTFS" timestamp is used on Windows platform (return size at line#2200 is not updated accordingly) http://cr.openjdk.java.net/~sherman/6303183/webrev/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java.sdiff.html The webrev is below http://cr.openjdk.java.net/~sherman/8015728/webrev/ The test now passes locally. I'm running the jprt to verify. Thanks, -Sherman From mandy.chung at oracle.com Thu Jun 6 23:46:20 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 06 Jun 2013 23:46:20 +0000 Subject: hg: jdk8/tl/jdk: 8016117: New sun.misc.FDBigInteger class as part of 7032154 Message-ID: <20130606234717.5A0624802F@hg.openjdk.java.net> Changeset: f5f54e493a64 Author: bpb Date: 2013-06-06 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5f54e493a64 8016117: New sun.misc.FDBigInteger class as part of 7032154 Reviewed-by: martin, iris Contributed-by: Sergey Kuksenko , Brian Burkhalter , Dmitry Nadezhin , Olivier Lagneau + src/share/classes/sun/misc/FDBigInteger.java From joe.darcy at oracle.com Fri Jun 7 01:07:35 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 06 Jun 2013 18:07:35 -0700 Subject: Review request for 8016101, javadoc typos for SerialRef and SerialStruct In-Reply-To: References: <51B0F252.4030504@oracle.com> Message-ID: <51B13257.5040508@oracle.com> Hi Lance, Looks fine; approved. Cheers, -Joe On 6/6/2013 1:41 PM, Lance Andersen - Oracle wrote: > Hi Aleksey, > > The change is 2 lines, not worth a webrev. Here it is again in case it was truncated in last email (looked OK on my end) > > > new-host-2:serial lanceandersen$ hg diff > diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialRef.java > --- a/src/share/classes/javax/sql/rowset/serial/SerialRef.java Tue May 28 15:22:30 2013 +0200 > +++ b/src/share/classes/javax/sql/rowset/serial/SerialRef.java Thu Jun 06 16:01:07 2013 -0400 > @@ -202,7 +202,7 @@ > } > > /** > - * Returns a clone of this {@code SerialRef}. . > + * Returns a clone of this {@code SerialRef}. > * The underlying {@code Ref} object will be set to null. > * > * @return a clone of this SerialRef > diff -r b4742d038100 src/share/classes/javax/sql/rowset/serial/SerialStruct.java > --- a/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Tue May 28 15:22:30 2013 +0200 > +++ b/src/share/classes/javax/sql/rowset/serial/SerialStruct.java Thu Jun 06 16:01:07 2013 -0400 > @@ -87,6 +87,7 @@ > * object for custom mapping the SQL structured type or any of its > * attributes that are SQL structured types. > * > + * @param in an instance of {@code Struct} > * @param map a java.util.Map object in which > * each entry consists of 1) a String object > * giving the fully qualified name of a UDT and 2) the > On Jun 6, 2013, at 4:34 PM, Aleksey Shipilev wrote: > >> Hi Lance, >> >> On 06/07/2013 12:09 AM, Lance Andersen - Oracle wrote: >>> Need a reviewer for this minor javadoc update for bug 8016101 >> (not a reviewer) The patch appears to be truncated, can you submit it as >> patch/webrev somewhere on the web (e.g. cr.openjdk.java.net)? >> >> -Aleksey. >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Alan.Bateman at oracle.com Fri Jun 7 05:42:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Jun 2013 06:42:05 +0100 Subject: RFR JDK-8015728: (zipfs) demo/zipfs/basic.sh failing In-Reply-To: <51B11527.6040607@oracle.com> References: <51B11527.6040607@oracle.com> Message-ID: <51B172AD.9030805@oracle.com> On 07/06/2013 00:03, Xueming Shen wrote: > Hi, > > Please help review the proposed change to fix the regression triggered > by the change for #6303183, in which the change failed to update the > written loc entry size correctly when the "NTFS" timestamp is used on > Windows platform (return size at line#2200 is not updated accordingly) > > http://cr.openjdk.java.net/~sherman/6303183/webrev/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java.sdiff.html > > > The webrev is below > > http://cr.openjdk.java.net/~sherman/8015728/webrev/ Easily missed. The update looks good to me. -Alan From huizhe.wang at oracle.com Fri Jun 7 06:03:41 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 06 Jun 2013 23:03:41 -0700 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B0C28D.7080100@oracle.com> References: <51B0C28D.7080100@oracle.com> Message-ID: <51B177BD.1000905@oracle.com> Hi Aleksej, According to XPath spec, both positive and negative zero are converted to the string 0, so it seems doesn't matter. But if you want to detect the negative zero, you may do the following: if (d == 0.0 && 1/d < 0.0) { d=0.0 } Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). -Joe On 6/6/2013 10:10 AM, Aleksej Efimov wrote: > Hi, > > The expression "string(-0.0)" incorrectly transformed to -0, but it > should be 0 according to W3C specification: > http://www.w3.org/TR/xpath/#function-string > > The webrev with fix and the test case: > http://cr.openjdk.java.net/~dmeetry/8015978/webrev.1/ > > > There is another way of disabling the -0 result. In current webrev the > minus zero is processed with such code: > > + > + //Check for -0.0 and convert it to 0.0 > + if (new Double(d).equals(new Double(-0.0)) > + d=0.0; > > We can make the replace of -0 -> 0 faster (I think but didn't tested > it) with the following code, but it looks strange and will work both > for 0 and -0: > > + //Check for -0.0 and convert it to 0.0 > + if (d == 0.0) > + d=0.0; > > -Aleksej From paul.sandoz at oracle.com Fri Jun 7 07:37:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 7 Jun 2013 09:37:14 +0200 Subject: hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API In-Reply-To: References: <20130603154340.F1AC048EE8@hg.openjdk.java.net> Message-ID: Hi Roel, Would you like to submit a patch and contribute? Paul. On Jun 4, 2013, at 4:16 PM, Roel Spilker wrote: > Looking at the implementation, the code in toString suggest that it's worthwhile to optimize for an empty suffix (although I doubt that this optimization has any measurable effects). But the constructor always concatenates the prefix and the suffix, which results in both a new string instance and a StringBuilder. If an empty suffix is common (actually, having a separate constructor and the current toString implementation both suggest it is), I think that the initializing the emptyValue field in the constructor should be written as: > > this.emptyValue = this.suffix.isEmpty() ? this.prefix : this.prefix + this.suffix; > > Actually, since there is also a setEmptyValue, I think that the field should be left null, and toString and length check for null, resulting in even less objects allocated in that scenario. > > Roel > > > > On Mon, Jun 3, 2013 at 5:43 PM, wrote: > Changeset: a79e2683eae3 > Author: psandoz > Date: 2013-06-03 17:37 +0200 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79e2683eae3 > > 8014383: StringJoiner example in class description not in sync with streams API > Reviewed-by: alanb > > ! src/share/classes/java/util/StringJoiner.java > > From david.holmes at oracle.com Fri Jun 7 07:53:06 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Jun 2013 17:53:06 +1000 Subject: Is there a better way to throw this exception? In-Reply-To: <51B0A348.70805@gmail.com> References: <51B0599D.4020906@oracle.com> <51B0A348.70805@gmail.com> Message-ID: <51B19162.9010809@oracle.com> Peter, On 7/06/2013 12:57 AM, Peter Levart wrote: > On 06/06/2013 11:42 AM, Weijun Wang wrote: >> Hi All >> >> I have a method that could throw two kinds of checked exceptions and >> possibly other unchecked ones: >> >> void once() throws One, Two >> >> Now I have a wrapper method that calls once() for multiple times, and >> want to throw the first exception if *all* fails. Now it looks like >> >> void multiple() throws One, Two { >> Exception saved = null; >> for (all chances) { >> try { >> once(); >> return; >> } catch (Exception e) { >> if (saved != null) saved = e; >> } >> } >> if (saved instanceof One) { >> throw (One)saved; >> } else if (saved instanceof One) { >> throw (Two)saved; >> } else if (saved instanceof RuntimeException) { >> throw (RuntimeException)saved; >> } else { >> // Not likely, but I've already wrote so many lines. >> throw new RuntimeException(saved); >> } >> } >> >> Is there any way I can make it shorter? > > Hi Max, > > If you don't mind re-throwing the last exception thrown instead of the > first and you can transform your for loop into a while loop, for example: > > void multiple() throws One, Two { > int tries = 10; > int i = 0; > while (true) { > try { > once(); > return; > } catch (Exception e) { > if (++i >= tries) { > throw e; > } > } > } > } > > > ...otherwise you can re-throw the first exception if you can extract the > first loop iteration out of the loop: > > > void multiple() throws One, Two { > try { > once(); // first chance > return; > } catch (Exception e) { > for (rest of chances) { > try { > once(); > return; > } > catch (Exception ignore) {} > } > throw e; > } > } But the first call need not throw. David ----- > > Regards, Peter > >> >> Thanks >> Max > From masayoshi.okutsu at oracle.com Fri Jun 7 08:07:54 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Fri, 07 Jun 2013 08:07:54 +0000 Subject: hg: jdk8/tl/jdk: 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces Message-ID: <20130607080817.D7B4C4806B@hg.openjdk.java.net> Changeset: 6975eea0b458 Author: okutsu Date: 2013-06-07 17:07 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6975eea0b458 7177315: SimpleDateFormat parses wrong 2-digit year if input contains spaces Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7177315.java From masayoshi.okutsu at oracle.com Fri Jun 7 08:38:03 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Fri, 07 Jun 2013 08:38:03 +0000 Subject: hg: jdk8/tl/jdk: 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8 Message-ID: <20130607083817.4D4F148072@hg.openjdk.java.net> Changeset: a286ed046116 Author: okutsu Date: 2013-06-07 17:37 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a286ed046116 7064270: java/text/Format/DateFormat/WeekDateTest.java fails on OEL5.6 hi_IN.UTF-8 Reviewed-by: peytoia ! test/java/text/Format/DateFormat/WeekDateTest.java From paul.sandoz at oracle.com Fri Jun 7 09:05:00 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 7 Jun 2013 11:05:00 +0200 Subject: RFR 8016139: PrimitiveIterator.forEachRemaining In-Reply-To: <36BDCF16-44EF-47C9-9331-1C42A21CB279@oracle.com> References: <36BDCF16-44EF-47C9-9331-1C42A21CB279@oracle.com> Message-ID: <7F3F6423-2686-45A8-8403-85C1F7EA2DC6@oracle.com> Hi, The following patch defines the abstract method PrimitiveIterator.forEachRemaining. This is now consistent with Spliterator.OfPrimitive and there may be cases in the future where this is useful and if we don't do it now it becomes difficult to do so later on. http://cr.openjdk.java.net/~psandoz/tl/JDK-8016139-primIter.forEachRem/webrev/ CCC is in progress. Paul. From alexey.utkin at oracle.com Fri Jun 7 09:02:57 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 07 Jun 2013 13:02:57 +0400 Subject: Request for review: 8016046 (process) Strict validation of input should be security manager case only [win] Message-ID: <51B1A1C1.9000608@oracle.com> Hi, Please review the fix. Bug description: http://bugs.sun.com/view_bug.do?bug_id=8016046 https://jbs.oracle.com/bugs/browse/JDK-8016046 The suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.00/ Summary: In absence of the Security Manager the verification procedure for the command-line was restored as before the JDK-8012453 fix. That suggests the ability of inline input/output redirection, piping, simultaneous launching of several programs by single command, lost spaces and etc. The extended verification procedure is activated in presence of the Security Manager or installing to "false" the "jdk.lang.Process.allowAmbiguousCommands" Java property. Regards, -uta From aleksey.shipilev at oracle.com Fri Jun 7 10:01:16 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 07 Jun 2013 14:01:16 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability Message-ID: <51B1AF6C.5030708@oracle.com> (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as Christian T. suggested offline) Hi guys, The fix for scalability problem is here: http://cr.openjdk.java.net/~shade/7177472/webrev.00/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK Since this is a proof-of-concept patch at this point, I kept the testing minimal. Let me know what other testing you think is needed before the integration. Thanks, Aleksey. *** Rationale and details for the issue follow: *** This issue was in limbo for an year. The performance issue with MethodType.methodType factory leads to abysmal scalability on the targeted tests. While this can arguably demonstrated on larger workloads, the targeted microbenchmarks are showcasing it nicely. This issue was blocking the JSR292 API performance testing, because on large enough test server, you will inevitably be bitten by this. If you run the JMH-enabled [1] microbenchmark: http://openjdk.java.net/projects/code-tools/jmh/ http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will see the scalability is going down. ("testCached" makes sure the reference to MethodType is always strongly reachable, "testNew" makes sure the reference is mostly non-reachable, prompting cache re-fill, "testOOB" does not make any precautions about that, and also does not suffer from the static overheads entailed by the reference management in first two tests). 1 thread: MethodTypeBench.testCached 78 +- 1 nsec/op MethodTypeBench.testNew 120 +- 1 nsec/op MethodTypeBench.testOOB 41 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 495 +- 40 nsec/op MethodTypeBench.testNew 611 +- 37 nsec/op MethodTypeBench.testOOB 377 +- 10 nsec/op In fact, on larger machines it may be as bad as tens/hundreds of microseconds to look up the MethodType. With the patch applied, on the same 2x2 machine: 1 thread: MethodTypeBench.testCached 92 +- 1 nsec/op MethodTypeBench.testNew 101 +- 1 nsec/op MethodTypeBench.testOOB 49 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 129 +- 1 nsec/op MethodTypeBench.testNew 142 +- 10 nsec/op MethodTypeBench.testOOB 89 +- 3 nsec/op ...which means the scalability is back: the average time to look up the MethodType is not growing spectacularly when the thread count go up. Again, the effect is astonishing on large machines. Notice that we took some hit in single-threaded performance, and that is due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the upcoming CHMv8, this starts to look better: 1 thread: MethodTypeBench.testCached 87 +- 1 nsec/op MethodTypeBench.testNew 95 +- 1 nsec/op MethodTypeBench.testOOB 52 +- 1 nsec/op 4 threads: MethodTypeBench.testCached 121 +- 2 nsec/op MethodTypeBench.testNew 141 +- 1 nsec/op MethodTypeBench.testOOB 93 +- 5 nsec/op ...which seems to indicate this change is future-proof. From otaviojava at java.net Fri Jun 7 13:18:27 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 10:18:27 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: con.sun. * java.lang*} Message-ID: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] The string addition in the parameter will create another string buffer, append all the components, then convert that to a string so the you can be appended to your string buffer. So I replace this: sb.append(" xxx: [" + getXXX() + "]\n"); for this: sb.append(" xxx: [").append(getXXX()).append("]\n"); The classes are: -- com.sun com.sun.tools.hat.internal.model.JavaValueArray com.sun.jmx.snmp.IPAcl.NetMaskImpl com.sun.jndi.ldap.sasl.DefaultCallbackHandler com.sun.media.sound.WaveExtensibleFileReader com.sun.org.apache.xml.internal.security.encryption.XMLCipher com.sun.org.apache.xml.internal.security.utils.RFC2253Parser com.sun.security.sasl.CramMD5Base com.sun.security.sasl.digest.DigestMD5Base com.sun.tools.example.debug.gui.ContextManager com.sun.tools.jdi.VirtualMachineImpl -- java.lang java.lang.invoke.LambdaForm The diff bellow: diff --git a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java @@ -338,10 +338,10 @@ if (classpath.isEmpty()) { String envcp = System.getProperty("env.class.path"); if ((envcp != null) && (envcp.length() > 0)) { - munged.append(" -classpath " + envcp); + munged.append(" -classpath ").append(envcp); } } else { - munged.append(" -classpath " + classpath.asString()); + munged.append(" -classpath ").append(classpath.asString()); } return munged.toString(); } else { diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java b/src/share/classes/com/sun/security/sasl/CramMD5Base.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java @@ -199,8 +199,7 @@ for (i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + - Integer.toHexString(digest[i] & 0x000000ff)); + digestString.append("0").append(Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( Integer.toHexString(digest[i] & 0x000000ff)); diff --git a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java @@ -90,7 +90,7 @@ if (selected == -1) { StringBuffer allChoices = new StringBuffer(); for (int j = 0; j < choices.length; j++) { - allChoices.append(choices[j] + ","); + allChoices.append(choices[j]).append(','); } throw new IOException("Cannot match " + "'java.naming.security.sasl.realm' property value, '" + diff --git a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java @@ -391,7 +391,7 @@ for (int i = 0; i < digest.length; i ++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0"+ + digestString.append("0").append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java @@ -386,37 +386,37 @@ } case 'B': { int val = 0xFF & byteAt(i, value); - result.append("0x" + Integer.toString(val, 16)); + result.append("0x").append(Integer.toString(val, 16)); i++; break; } case 'S': { short val = shortAt(i, value); i += 2; - result.append("" + val); + result.append("").append(val); break; } case 'I': { int val = intAt(i, value); i += 4; - result.append("" + val); + result.append("").append( val); break; } case 'J': { // long long val = longAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } case 'F': { float val = floatAt(i, value); - result.append("" + val); + result.append("").append(val); i += 4; break; } case 'D': { // double double val = doubleAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java @@ -65,7 +65,7 @@ "extractSubNet", "BINARY ARRAY :"); StringBuffer buff = new StringBuffer(); for(int i =0; i < addrLength; i++) { - buff.append((b[i] &0xFF) +":"); + buff.append((b[i] &0xFF)).append(":"); } SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), "extractSubNet", buff.toString()); diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java @@ -98,7 +98,7 @@ l += countQuotes(_DN, j, k); if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); i = k + 1; l = 0; @@ -131,8 +131,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); - + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); i = k + 1; l = 0; } @@ -386,7 +385,7 @@ int k; for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { - sb.append(trim(string.substring(i, k)) + "\\ "); + sb.append(trim(string.substring(i, k))).append("\\ "); i = k + 3; } @@ -436,7 +435,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(trim(str.substring(i, k)) + replace); + sb.append(trim(str.substring(i, k))).append(replace); i = k + 1; l = 0; diff --git a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java @@ -338,10 +338,10 @@ if (classpath.isEmpty()) { String envcp = System.getProperty("env.class.path"); if ((envcp != null) && (envcp.length() > 0)) { - munged.append(" -classpath " + envcp); + munged.append(" -classpath ").append(envcp); } } else { - munged.append(" -classpath " + classpath.asString()); + munged.append(" -classpath ").append(classpath.asString()); } return munged.toString(); } else { diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java b/src/share/classes/com/sun/security/sasl/CramMD5Base.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java @@ -199,8 +199,7 @@ for (i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + - Integer.toHexString(digest[i] & 0x000000ff)); + digestString.append("0").append(Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( Integer.toHexString(digest[i] & 0x000000ff)); diff --git a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java @@ -90,7 +90,7 @@ if (selected == -1) { StringBuffer allChoices = new StringBuffer(); for (int j = 0; j < choices.length; j++) { - allChoices.append(choices[j] + ","); + allChoices.append(choices[j]).append(','); } throw new IOException("Cannot match " + "'java.naming.security.sasl.realm' property value, '" + diff --git a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java @@ -391,7 +391,7 @@ for (int i = 0; i < digest.length; i ++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0"+ + digestString.append("0").append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java @@ -386,37 +386,37 @@ } case 'B': { int val = 0xFF & byteAt(i, value); - result.append("0x" + Integer.toString(val, 16)); + result.append("0x").append(Integer.toString(val, 16)); i++; break; } case 'S': { short val = shortAt(i, value); i += 2; - result.append("" + val); + result.append("").append(val); break; } case 'I': { int val = intAt(i, value); i += 4; - result.append("" + val); + result.append("").append( val); break; } case 'J': { // long long val = longAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } case 'F': { float val = floatAt(i, value); - result.append("" + val); + result.append("").append(val); i += 4; break; } case 'D': { // double double val = doubleAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java @@ -65,7 +65,7 @@ "extractSubNet", "BINARY ARRAY :"); StringBuffer buff = new StringBuffer(); for(int i =0; i < addrLength; i++) { - buff.append((b[i] &0xFF) +":"); + buff.append((b[i] &0xFF)).append(":"); } SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), "extractSubNet", buff.toString()); diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java @@ -98,7 +98,7 @@ l += countQuotes(_DN, j, k); if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); i = k + 1; l = 0; @@ -131,8 +131,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); - + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); i = k + 1; l = 0; } @@ -386,7 +385,7 @@ int k; for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { - sb.append(trim(string.substring(i, k)) + "\\ "); + sb.append(trim(string.substring(i, k))).append("\\ "); i = k + 3; } @@ -436,7 +435,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(trim(str.substring(i, k)) + replace); + sb.append(trim(str.substring(i, k))).append(replace); i = k + 1; l = 0; diff --git a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java @@ -338,10 +338,10 @@ if (classpath.isEmpty()) { String envcp = System.getProperty("env.class.path"); if ((envcp != null) && (envcp.length() > 0)) { - munged.append(" -classpath " + envcp); + munged.append(" -classpath ").append(envcp); } } else { - munged.append(" -classpath " + classpath.asString()); + munged.append(" -classpath ").append(classpath.asString()); } return munged.toString(); } else { diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java b/src/share/classes/com/sun/security/sasl/CramMD5Base.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java @@ -199,8 +199,7 @@ for (i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + - Integer.toHexString(digest[i] & 0x000000ff)); + digestString.append("0").append(Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( Integer.toHexString(digest[i] & 0x000000ff)); diff --git a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java @@ -90,7 +90,7 @@ if (selected == -1) { StringBuffer allChoices = new StringBuffer(); for (int j = 0; j < choices.length; j++) { - allChoices.append(choices[j] + ","); + allChoices.append(choices[j]).append(','); } throw new IOException("Cannot match " + "'java.naming.security.sasl.realm' property value, '" + diff --git a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java @@ -391,7 +391,7 @@ for (int i = 0; i < digest.length; i ++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0"+ + digestString.append("0").append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java @@ -386,37 +386,37 @@ } case 'B': { int val = 0xFF & byteAt(i, value); - result.append("0x" + Integer.toString(val, 16)); + result.append("0x").append(Integer.toString(val, 16)); i++; break; } case 'S': { short val = shortAt(i, value); i += 2; - result.append("" + val); + result.append("").append(val); break; } case 'I': { int val = intAt(i, value); i += 4; - result.append("" + val); + result.append("").append( val); break; } case 'J': { // long long val = longAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } case 'F': { float val = floatAt(i, value); - result.append("" + val); + result.append("").append(val); i += 4; break; } case 'D': { // double double val = doubleAt(i, value); - result.append("" + val); + result.append("").append(val); i += 8; break; } diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java @@ -65,7 +65,7 @@ "extractSubNet", "BINARY ARRAY :"); StringBuffer buff = new StringBuffer(); for(int i =0; i < addrLength; i++) { - buff.append((b[i] &0xFF) +":"); + buff.append((b[i] &0xFF)).append(":"); } SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), "extractSubNet", buff.toString()); diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java @@ -98,7 +98,7 @@ l += countQuotes(_DN, j, k); if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); i = k + 1; l = 0; @@ -131,8 +131,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); - + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); i = k + 1; l = 0; } @@ -386,7 +385,7 @@ int k; for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { - sb.append(trim(string.substring(i, k)) + "\\ "); + sb.append(trim(string.substring(i, k))).append("\\ "); i = k + 3; } @@ -436,7 +435,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(trim(str.substring(i, k)) + replace); + sb.append(trim(str.substring(i, k))).append(replace); i = k + 1; l = 0; diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java @@ -881,10 +881,10 @@ } else if (tag == JDWP.TypeTag.ARRAY) { sb.append("ArrayType"); } else { - sb.append("UNKNOWN TAG: " + tag); + sb.append("UNKNOWN TAG: ").append(tag); } if (signature != null) { - sb.append(", signature='" + signature + "'"); + sb.append(", signature='").append(signature).append("'"); } sb.append(", id=" + id); vm.printTrace(sb.toString()); diff --git a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java @@ -167,9 +167,9 @@ for (int i = 0; i < allchannelnames.length; i++) { if ((channelmask & m) != 0L) { if (i < channelnames.length) { - sb.append(channelnames[i] + " "); + sb.append(channelnames[i]).append(" "); } else { - sb.append(allchannelnames[i] + " "); + sb.append(allchannelnames[i]).append(" "); } } m *= 2L; diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java @@ -1932,7 +1932,7 @@ StringBuffer sb; sb = new StringBuffer(); - sb.append("<"+tagname); + sb.append("<").append(tagname); // Run through each node up to the document node and find any // xmlns: nodes diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java @@ -881,10 +881,10 @@ } else if (tag == JDWP.TypeTag.ARRAY) { sb.append("ArrayType"); } else { - sb.append("UNKNOWN TAG: " + tag); + sb.append("UNKNOWN TAG: ").append(tag); } if (signature != null) { - sb.append(", signature='" + signature + "'"); + sb.append(", signature='").append(signature).append("'"); } sb.append(", id=" + id); vm.printTrace(sb.toString()); diff --git a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java @@ -167,9 +167,9 @@ for (int i = 0; i < allchannelnames.length; i++) { if ((channelmask & m) != 0L) { if (i < channelnames.length) { - sb.append(channelnames[i] + " "); + sb.append(channelnames[i]).append(" "); } else { - sb.append(allchannelnames[i] + " "); + sb.append(allchannelnames[i]).append(" "); } } m *= 2L; diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java @@ -1932,7 +1932,7 @@ StringBuffer sb; sb = new StringBuffer(); - sb.append("<"+tagname); + sb.append("<").append(tagname); // Run through each node up to the document node and find any // xmlns: nodes diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java @@ -881,10 +881,10 @@ } else if (tag == JDWP.TypeTag.ARRAY) { sb.append("ArrayType"); } else { - sb.append("UNKNOWN TAG: " + tag); + sb.append("UNKNOWN TAG: ").append(tag); } if (signature != null) { - sb.append(", signature='" + signature + "'"); + sb.append(", signature='").append(signature).append("'"); } sb.append(", id=" + id); vm.printTrace(sb.toString()); diff --git a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java @@ -167,9 +167,9 @@ for (int i = 0; i < allchannelnames.length; i++) { if ((channelmask & m) != 0L) { if (i < channelnames.length) { - sb.append(channelnames[i] + " "); + sb.append(channelnames[i]).append(" "); } else { - sb.append(allchannelnames[i] + " "); + sb.append(allchannelnames[i]).append(" "); } } m *= 2L; diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java @@ -1932,7 +1932,7 @@ StringBuffer sb; sb = new StringBuffer(); - sb.append("<"+tagname); + sb.append("<").append(tagname); // Run through each node up to the document node and find any // xmlns: nodes -- java_lang diff --git a/src/share/classes/java/lang/invoke/LambdaForm.java b/src/share/classes/java/lang/invoke/LambdaForm.java --- a/src/share/classes/java/lang/invoke/LambdaForm.java +++ b/src/share/classes/java/lang/invoke/LambdaForm.java @@ -708,7 +708,7 @@ } public String toString() { - StringBuilder buf = new StringBuilder(debugName+"=Lambda("); + StringBuilder buf = new StringBuilder(debugName).append("=Lambda("); for (int i = 0; i < names.length; i++) { if (i == arity) buf.append(")=>{"); Name n = names[i]; -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviojava at java.net Fri Jun 7 13:22:33 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 10:22:33 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: sun.*} Message-ID: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] The string addition in the parameter will create another string buffer, append all the components, then convert that to a string so the you can be appended to your string buffer. So I replace this: sb.append(" xxx: [" + getXXX() + "]\n"); for this: sb.append(" xxx: [").append(getXXX()).append("]\n"); The classes are: -- sun sun.awt.datatransfer.SunClipboard sun.font.Decoration sun.font.StandardGlyphVector sun.management.Agent sun.net.www.MimeEntry sun.reflect.annotation.AnnotationType sun.tools.jstatd.RemoteHostImpl sun.security.acl.AclEntryImpl sun.security.krb5.internal.crypto.dk.DkCrypto sun.security.krb5.KrbException sun.security.pkcs.SigningCertificateInfo sun.security.ssl.HandshakeMessage sun.security.x509.PolicyInformation sun.security.x509.X509CRLImpl The diff bellow: diff --git a/src/share/classes/sun/management/Agent.java b/src/share/classes/sun/management/Agent.java --- a/src/share/classes/sun/management/Agent.java +++ b/src/share/classes/sun/management/Agent.java @@ -497,7 +497,7 @@ } else { StringBuffer message = new StringBuffer(params[0]); for (int i = 1; i < params.length; i++) { - message.append(" " + params[i]); + message.append(" ").append(params[i]); } error(key, message.toString()); } diff --git a/src/share/classes/sun/reflect/annotation/AnnotationType.java b/src/share/classes/sun/reflect/annotation/AnnotationType.java --- a/src/share/classes/sun/reflect/annotation/AnnotationType.java +++ b/src/share/classes/sun/reflect/annotation/AnnotationType.java @@ -205,11 +205,11 @@ * For debugging. */ public String toString() { - StringBuffer s = new StringBuffer("Annotation Type:" + "\n"); - s.append(" Member types: " + memberTypes + "\n"); - s.append(" Member defaults: " + memberDefaults + "\n"); - s.append(" Retention policy: " + retention + "\n"); - s.append(" Inherited: " + inherited); + StringBuffer s = new StringBuffer("Annotation Type:").append("\n"); + s.append(" Member types: " ).append( memberTypes ).append( "\n"); + s.append(" Member defaults: " ).append( memberDefaults ).append( "\n"); + s.append(" Retention policy: " ).append( retention ).append( "\n"); + s.append(" Inherited: " ).append( inherited); return s.toString(); } } diff --git a/src/share/classes/sun/font/Decoration.java b/src/share/classes/sun/font/Decoration.java --- a/src/share/classes/sun/font/Decoration.java +++ b/src/share/classes/sun/font/Decoration.java @@ -430,12 +430,12 @@ StringBuffer buf = new StringBuffer(); buf.append(super.toString()); buf.append("["); - if (fgPaint != null) buf.append("fgPaint: " + fgPaint); - if (bgPaint != null) buf.append(" bgPaint: " + bgPaint); + if (fgPaint != null) buf.append("fgPaint: ").append(fgPaint); + if (bgPaint != null) buf.append(" bgPaint: ").append(bgPaint); if (swapColors) buf.append(" swapColors: true"); if (strikethrough) buf.append(" strikethrough: true"); - if (stdUnderline != null) buf.append(" stdUnderline: " + stdUnderline); - if (imUnderline != null) buf.append(" imUnderline: " + imUnderline); + if (stdUnderline != null) buf.append(" stdUnderline: ").append(stdUnderline); + if (imUnderline != null) buf.append(" imUnderline: ").append(imUnderline); buf.append("]"); return buf.toString(); } diff --git a/src/share/classes/sun/net/www/MimeEntry.java b/src/share/classes/sun/net/www/MimeEntry.java --- a/src/share/classes/sun/net/www/MimeEntry.java +++ b/src/share/classes/sun/net/www/MimeEntry.java @@ -297,7 +297,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("application=" + command); + buf.append("application=").append(command); needSeparator = true; } @@ -305,7 +305,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("icon=" + getImageFileName()); + buf.append("icon=").append(getImageFileName()); needSeparator = true; } @@ -314,7 +314,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("file_extensions=" + extensions); + buf.append("file_extensions=").append(extensions); needSeparator = true; } @@ -323,7 +323,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("description=" + description); + buf.append("description=" ).append(description); } return buf.toString(); diff --git a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java --- a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java +++ b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java @@ -68,7 +68,7 @@ sb.append("local://").append(lvmid).append("@localhost"); if (mode != null) { - sb.append("?mode=" + mode); + sb.append("?mode=").append(mode); } String vmidStr = sb.toString(); diff --git a/src/share/classes/sun/font/StandardGlyphVector.java b/src/share/classes/sun/font/StandardGlyphVector.java --- a/src/share/classes/sun/font/StandardGlyphVector.java +++ b/src/share/classes/sun/font/StandardGlyphVector.java @@ -1894,7 +1894,7 @@ } } catch(Exception e) { - buf.append(" " + e.getMessage()); + buf.append(" ").append(e.getMessage()); } buf.append("}"); diff --git a/src/share/classes/sun/awt/datatransfer/SunClipboard.java b/src/share/classes/sun/awt/datatransfer/SunClipboard.java --- a/src/share/classes/sun/awt/datatransfer/SunClipboard.java +++ b/src/share/classes/sun/awt/datatransfer/SunClipboard.java @@ -87,7 +87,7 @@ public SunClipboard(String name) { super(name); - CLIPBOARD_FLAVOR_LISTENER_KEY = new StringBuffer(name + "_CLIPBOARD_FLAVOR_LISTENER_KEY"); + CLIPBOARD_FLAVOR_LISTENER_KEY = new StringBuffer(name).append("_CLIPBOARD_FLAVOR_LISTENER_KEY"); } public synchronized void setContents(Transferable contents, diff --git a/src/share/classes/sun/security/acl/AclEntryImpl.java b/src/share/classes/sun/security/acl/AclEntryImpl.java --- a/src/share/classes/sun/security/acl/AclEntryImpl.java +++ b/src/share/classes/sun/security/acl/AclEntryImpl.java @@ -147,7 +147,7 @@ s.append("Group."); else s.append("User."); - s.append(user + "="); + s.append(user).append("="); Enumeration e = permissions(); while(e.hasMoreElements()) { Permission p = e.nextElement(); diff --git a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java --- a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java +++ b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java @@ -640,7 +640,7 @@ for (int i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + + digestString.append("0").append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/sun/security/ssl/HandshakeMessage.java b/src/share/classes/sun/security/ssl/HandshakeMessage.java --- a/src/share/classes/sun/security/ssl/HandshakeMessage.java +++ b/src/share/classes/sun/security/ssl/HandshakeMessage.java @@ -1478,7 +1478,7 @@ boolean opened = false; for (SignatureAndHashAlgorithm signAlg : algorithms) { if (opened) { - buffer.append(", " + signAlg.getAlgorithmName()); + buffer.append(", ").append(signAlg.getAlgorithmName()); } else { buffer.append(signAlg.getAlgorithmName()); opened = true; diff --git a/src/share/classes/sun/security/krb5/KrbException.java b/src/share/classes/sun/security/krb5/KrbException.java --- a/src/share/classes/sun/security/krb5/KrbException.java +++ b/src/share/classes/sun/security/krb5/KrbException.java @@ -96,7 +96,7 @@ public String krbErrorMessage() { - StringBuffer strbuf = new StringBuffer("krb_error " + returnCode); + StringBuffer strbuf = new StringBuffer("krb_error ").append(returnCode); String msg = getMessage(); if (msg != null) { strbuf.append(" "); diff --git a/src/share/classes/sun/security/x509/PolicyInformation.java b/src/share/classes/sun/security/x509/PolicyInformation.java --- a/src/share/classes/sun/security/x509/PolicyInformation.java +++ b/src/share/classes/sun/security/x509/PolicyInformation.java @@ -258,8 +258,8 @@ * Return a printable representation of the PolicyInformation. */ public String toString() { - StringBuilder s = new StringBuilder(" [" + policyIdentifier.toString()); - s.append(policyQualifiers + " ]\n"); + StringBuilder s = new StringBuilder(" [").append( policyIdentifier.toString()); + s.append(policyQualifiers).append(" ]\n"); return s.toString(); } diff --git a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java --- a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java +++ b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java @@ -158,8 +158,8 @@ } buffer.append(hexDumper.encode(certHash)); if (issuer != null && serialNumber != null) { - buffer.append("\n\tIssuer: " + issuer + "\n"); - buffer.append("\t" + serialNumber); + buffer.append("\n\tIssuer: " ).append( issuer ).append( "\n"); + buffer.append("\t").append( serialNumber); } buffer.append("\n]"); return buffer.toString(); -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviojava at java.net Fri Jun 7 13:25:49 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 10:25:49 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: java. * without Swing} Message-ID: The string addition in the parameter will create another string buffer, append all the components, then convert that to a string so the you can be appended to your string buffer. So I replace this: sb.append(" xxx: [" + getXXX() + "]\n"); for this: sb.append(" xxx: [").append(getXXX()).append("]\n"); The classes are: javax.imageio.plugins.jpeg.JPEGQTable javax.management.openmbean.ArrayType javax.naming.BinaryRefAddr javax.naming.directory.BasicAttribute javax.naming.NameImpl javax.sound.sampled.AudioFileFormat The diff bellow: diff --git a/src/share/classes/javax/management/openmbean/ArrayType.java b/src/share/classes/javax/management/openmbean/ArrayType.java --- a/src/share/classes/javax/management/openmbean/ArrayType.java +++ b/src/share/classes/javax/management/openmbean/ArrayType.java @@ -459,7 +459,7 @@ isPrimitiveArray = at.isPrimitiveArray(); } StringBuilder result = - new StringBuilder(dimension + "-dimension array of "); + new StringBuilder(dimension).append("-dimension array of "); final String elementClassName = elementType.getClassName(); if (isPrimitiveArray) { // Convert from wrapper type to primitive type diff --git a/src/share/classes/javax/sound/sampled/AudioFileFormat.java b/src/share/classes/javax/sound/sampled/AudioFileFormat.java --- a/src/share/classes/javax/sound/sampled/AudioFileFormat.java +++ b/src/share/classes/javax/sound/sampled/AudioFileFormat.java @@ -288,19 +288,20 @@ //$$fb2002-11-01: fix for 4672864: AudioFileFormat.toString() throws unexpected NullPointerException if (type != null) { - buf.append(type.toString() + " (." + type.getExtension() + ") file"); + buf.append(type.toString()).append(" (.").append(type.getExtension()).append(") file"); + } else { buf.append("unknown file format"); } if (byteLength != AudioSystem.NOT_SPECIFIED) { - buf.append(", byte length: " + byteLength); + buf.append(", byte length: ").append(byteLength); } - buf.append(", data format: " + format); + buf.append(", data format: ").append(format); if (frameLength != AudioSystem.NOT_SPECIFIED) { - buf.append(", frame length: " + frameLength); + buf.append(", frame length: ").append(frameLength); } return new String(buf); diff --git a/src/share/classes/javax/naming/directory/BasicAttribute.java b/src/share/classes/javax/naming/directory/BasicAttribute.java --- a/src/share/classes/javax/naming/directory/BasicAttribute.java +++ b/src/share/classes/javax/naming/directory/BasicAttribute.java @@ -211,7 +211,7 @@ * @return The non-null string representation of this attribute. */ public String toString() { - StringBuffer answer = new StringBuffer(attrID + ": "); + StringBuffer answer = new StringBuffer(attrID).append(": "); if (values.size() == 0) { answer.append("No values"); } else { diff --git a/src/share/classes/javax/naming/BinaryRefAddr.java b/src/share/classes/javax/naming/BinaryRefAddr.java --- a/src/share/classes/javax/naming/BinaryRefAddr.java +++ b/src/share/classes/javax/naming/BinaryRefAddr.java @@ -169,7 +169,7 @@ str.append("AddressContents: "); for (int i = 0; i= 32) str.append(" ...\n"); diff --git a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java --- a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java +++ b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java @@ -197,7 +197,7 @@ */ public String toString() { String ls = System.getProperty("line.separator", "\n"); - StringBuilder sb = new StringBuilder("JPEGQTable:"+ls); + StringBuilder sb = new StringBuilder("JPEGQTable:").append(ls); for (int i=0; i < qTable.length; i++) { if (i % 8 == 0) { sb.append('\t'); diff --git a/src/share/classes/javax/naming/NameImpl.java b/src/share/classes/javax/naming/NameImpl.java --- a/src/share/classes/javax/naming/NameImpl.java +++ b/src/share/classes/javax/naming/NameImpl.java @@ -170,7 +170,7 @@ endQuote = one ? syntaxEndQuote1 : syntaxEndQuote2; i += syntaxTypevalSeparator.length(); - answer.append(syntaxTypevalSeparator+beginQuote); // add back + answer.append(syntaxTypevalSeparator).append(beginQuote); // add back // consume string until matching quote for (i += beginQuote.length(); -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From aph at redhat.com Fri Jun 7 13:54:06 2013 From: aph at redhat.com (Andrew Haley) Date: Fri, 07 Jun 2013 14:54:06 +0100 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: con.sun. * java.lang*} In-Reply-To: References: Message-ID: <51B1E5FE.9070807@redhat.com> On 06/07/2013 02:18 PM, Ot?vio Gon?alves de Santana wrote: > Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] > > The string addition in the parameter will create another string buffer, > append all the components, then convert that to a string so the you can be > appended to your string buffer. > > So I replace this: > > sb.append(" xxx: [" + getXXX() + "]\n"); > > for this: > > sb.append(" xxx: [").append(getXXX()).append("]\n"); Hmm. I wonder that a JIT can't do this automatically. Perhaps it already does; I haven't looked. Andrew. From tom.hawtin at oracle.com Fri Jun 7 14:09:09 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 07 Jun 2013 15:09:09 +0100 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: con.sun. * java.lang*} In-Reply-To: <51B1E5FE.9070807@redhat.com> References: <51B1E5FE.9070807@redhat.com> Message-ID: <51B1E985.3030807@oracle.com> On 07/06/2013 14:54, Andrew Haley wrote: > On 06/07/2013 02:18 PM, Ot?vio Gon?alves de Santana wrote: >> sb.append(" xxx: [" + getXXX() + "]\n"); >> >> for this: >> >> sb.append(" xxx: [").append(getXXX()).append("]\n"); > > Hmm. I wonder that a JIT can't do this automatically. Perhaps > it already does; I haven't looked. The capacity of the StringBuilder may be different for the two statements. So even a "high-level rewriting" wouldn't be sufficiently equivalent. Tom From Alan.Bateman at oracle.com Fri Jun 7 15:35:50 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Jun 2013 16:35:50 +0100 Subject: RFR 8016139: PrimitiveIterator.forEachRemaining In-Reply-To: <7F3F6423-2686-45A8-8403-85C1F7EA2DC6@oracle.com> References: <36BDCF16-44EF-47C9-9331-1C42A21CB279@oracle.com> <7F3F6423-2686-45A8-8403-85C1F7EA2DC6@oracle.com> Message-ID: <51B1FDD6.3080109@oracle.com> On 07/06/2013 10:05, Paul Sandoz wrote: > Hi, > > The following patch defines the abstract method PrimitiveIterator.forEachRemaining. This is now consistent with Spliterator.OfPrimitive and there may be cases in the future where this is useful and if we don't do it now it becomes difficult to do so later on. > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016139-primIter.forEachRem/webrev/ > > CCC is in progress. > > Paul. Looks fine to me. I guess I would have intented the second/subsequent line of the @param description or alternative put in a blank line before the next tag, just to make it obvious where the description ends. -Alan. From david.r.chase at oracle.com Fri Jun 7 15:43:28 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 7 Jun 2013 11:43:28 -0400 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B177BD.1000905@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> Message-ID: Wouldn't be more efficient to do the following, assuming that the full Java compilation chain respects the trickiness of 0 vs -0: if (d == 0.0) { d=0.0 // Jam -0 == +0 to +0, per http://www.w3.org/TR/xpath/#function-string } Division's plenty more expensive than assigning a constant, especially on platforms that lack hardware FP division. David On 2013-06-07, at 2:03 AM, huizhe wang wrote: > Hi Aleksej, > > According to XPath spec, both positive and negative zero are converted to the string 0, so it seems doesn't matter. But if you want to detect the negative zero, you may do the following: > if (d == 0.0 && 1/d < 0.0) { > d=0.0 > } > > Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). > > -Joe From otaviojava at java.net Fri Jun 7 15:46:16 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 12:46:16 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: con.sun. * java.lang*} In-Reply-To: <51B1E985.3030807@oracle.com> References: <51B1E5FE.9070807@redhat.com> <51B1E985.3030807@oracle.com> Message-ID: I wrote a simple test. public class BuilderTest{ public void testAppend(String name){ StringBuilder sb=new StringBuilder(); sb.append("hello").append(" World: ").append(name); } public void testConcat(String name){ StringBuilder sb=new StringBuilder(); sb.append("hello" +" World: "+name); } } public void testAppend(java.lang.String); Code: Stack=2, Locals=3, Args_size=2 0: new #2; //class java/lang/StringBuilder 3: dup 4: invokespecial #3; //Method java/lang/StringBuilder."":()V 7: astore_2 8: aload_2 9: ldc #4; //String hello 11: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 14: ldc #6; //String World: 16: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 19: aload_1 20: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 23: pop 24: return public void testConcat(java.lang.String); Code: Stack=3, Locals=3, Args_size=2 0: new #2; //class java/lang/StringBuilder 3: dup 4: invokespecial #3; //Method java/lang/StringBuilder."":()V 7: astore_2 8: aload_2 9: new #2; //class java/lang/StringBuilder 12: dup 13: invokespecial #3; //Method java/lang/StringBuilder."":()V 16: ldc #7; //String hello World: 18: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 21: aload_1 22: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 25: invokevirtual #8; //Method java/lang/StringBuilder.toString:()Ljava/la ng/String; 28: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/ String;)Ljava/lang/StringBuilder; 31: pop 32: return } In the second method it creates a second StringBuilder with the toString() of the first one. I think doing this get some performance. On Fri, Jun 7, 2013 at 11:09 AM, Tom Hawtin wrote: > On 07/06/2013 14:54, Andrew Haley wrote: > >> On 06/07/2013 02:18 PM, Ot?vio Gon?alves de Santana wrote: >> > > sb.append(" xxx: [" + getXXX() + "]\n"); >>> >>> for this: >>> >>> sb.append(" xxx: [").append(getXXX()).append("]**\n"); >>> >> >> Hmm. I wonder that a JIT can't do this automatically. Perhaps >> it already does; I haven't looked. >> > > The capacity of the StringBuilder may be different for the two statements. > So even a "high-level rewriting" wouldn't be sufficiently equivalent. > > Tom > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From Alan.Bateman at oracle.com Fri Jun 7 16:02:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 07 Jun 2013 17:02:07 +0100 Subject: Request for review: 8016046 (process) Strict validation of input should be security manager case only [win] In-Reply-To: <51B1A1C1.9000608@oracle.com> References: <51B1A1C1.9000608@oracle.com> Message-ID: <51B203FF.5010604@oracle.com> On 07/06/2013 10:02, Alexey Utkin wrote: > Hi, > Please review the fix. > > Bug description: > http://bugs.sun.com/view_bug.do?bug_id=8016046 > https://jbs.oracle.com/bugs/browse/JDK-8016046 > > The suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.00/ > > Summary: > In absence of the Security Manager the verification procedure for > the command-line was restored as before the JDK-8012453 fix. That > suggests the ability of inline input/output redirection, piping, > simultaneous launching of several programs by single command, lost > spaces and etc. > The extended verification procedure is activated in presence of the > Security Manager or installing to "false" the > "jdk.lang.Process.allowAmbiguousCommands" Java property. Given 15 years of sloppy usage of Runtime.exec on Windows then it was always going to be difficult to switch to tighter checking by default. So I think the solution is right and keeps existing code working. I also agree that it's useful to have a property to opt-in to get property checking of the input. So the changes looks good to me. A minor comment on the test but in checkOut then it could use Files.notExists. It would be useful to expand the @bug to include the new bug ID too. -Alan. From paul.sandoz at oracle.com Fri Jun 7 16:26:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 7 Jun 2013 18:26:19 +0200 Subject: RFR 8016139: PrimitiveIterator.forEachRemaining In-Reply-To: <51B1FDD6.3080109@oracle.com> References: <36BDCF16-44EF-47C9-9331-1C42A21CB279@oracle.com> <7F3F6423-2686-45A8-8403-85C1F7EA2DC6@oracle.com> <51B1FDD6.3080109@oracle.com> Message-ID: On Jun 7, 2013, at 5:35 PM, Alan Bateman wrote: > On 07/06/2013 10:05, Paul Sandoz wrote: >> Hi, >> >> The following patch defines the abstract method PrimitiveIterator.forEachRemaining. This is now consistent with Spliterator.OfPrimitive and there may be cases in the future where this is useful and if we don't do it now it becomes difficult to do so later on. >> >> http://cr.openjdk.java.net/~psandoz/tl/JDK-8016139-primIter.forEachRem/webrev/ >> >> CCC is in progress. >> >> Paul. > Looks fine to me. Thanks. > I guess I would have intented the second/subsequent line of the @param description or alternative put in a blank line before the next tag, just to make it obvious where the description ends. > I will update with indentation. Paul. From joe.darcy at oracle.com Fri Jun 7 17:19:46 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Jun 2013 10:19:46 -0700 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> Message-ID: <51B21632.2020309@oracle.com> I'll do you one better; you can turn a negative zero into a positive zero leaving other values unchanged like this: d = d + 0.0; In IEEE 754 under the round-to-nearest-even rounding mode required by Java -0.0 + 0.0 => (+)0.0 This trick is used in various places in Java's numerical libraries, is required behavior by our specifications, and even has some tests for it :-) -Joe On 6/7/2013 8:43 AM, David Chase wrote: > Wouldn't be more efficient to do the following, assuming that the full Java compilation chain respects the trickiness of 0 vs -0: > > if (d == 0.0) { > d=0.0 // Jam -0 == +0 to +0, per http://www.w3.org/TR/xpath/#function-string > > } > > Division's plenty more expensive than assigning a constant, especially on platforms that lack hardware FP division. > > David > > On 2013-06-07, at 2:03 AM, huizhe wang wrote: > >> Hi Aleksej, >> >> According to XPath spec, both positive and negative zero are converted to the string 0, so it seems doesn't matter. But if you want to detect the negative zero, you may do the following: >> if (d == 0.0 && 1/d < 0.0) { >> d=0.0 >> } >> >> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >> >> -Joe > From kurchi.subhra.hazra at oracle.com Fri Jun 7 17:49:52 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 07 Jun 2013 17:49:52 +0000 Subject: hg: jdk8/tl/jdk: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER Message-ID: <20130607175035.C1DD5480A7@hg.openjdk.java.net> Changeset: 8b65dfe8f509 Author: khazra Date: 2013-06-07 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b65dfe8f509 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER Summary: Return false for null arguments in ACCEPT_ORIGINAL_SERVER#shouldAccept() Reviewed-by: chegar ! src/share/classes/java/net/CookiePolicy.java ! test/java/net/CookieHandler/CookieManagerTest.java From mike.duigou at oracle.com Fri Jun 7 17:58:26 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 7 Jun 2013 10:58:26 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} Message-ID: Hello all; I've incorporated feedback from previous rounds and expect to finalize this addition soon. http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ Any review feedback or suggestions of additional tests welcome. Thanks, Mike From lance.andersen at oracle.com Fri Jun 7 18:13:55 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 07 Jun 2013 18:13:55 +0000 Subject: hg: jdk8/tl/jdk: 8016101: Fix typo in SerialRef and missing @param in SerialStruct Message-ID: <20130607181409.74D53480AB@hg.openjdk.java.net> Changeset: e2333bd8514a Author: lancea Date: 2013-06-07 14:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2333bd8514a 8016101: Fix typo in SerialRef and missing @param in SerialStruct Reviewed-by: darcy ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java From huizhe.wang at oracle.com Fri Jun 7 19:11:44 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 7 Jun 2013 12:11:44 -0700 (PDT) Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B21632.2020309@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> <51B21632.2020309@oracle.com> Message-ID: <51B23070.6020006@oracle.com> Nice. One-line change, I guess Aleksej would love it :-) On 6/7/2013 10:19 AM, Joe Darcy wrote: > I'll do you one better; you can turn a negative zero into a positive > zero leaving other values unchanged like this: > > d = d + 0.0; > > In IEEE 754 under the round-to-nearest-even rounding mode required by > Java > -0.0 + 0.0 => (+)0.0 > > This trick is used in various places in Java's numerical libraries, is > required behavior by our specifications, and even has some tests for > it :-) > > -Joe > > On 6/7/2013 8:43 AM, David Chase wrote: >> Wouldn't be more efficient to do the following, assuming that the >> full Java compilation chain respects the trickiness of 0 vs -0: >> >> if (d == 0.0) { >> d=0.0 // Jam -0 == +0 to +0, per >> http://www.w3.org/TR/xpath/#function-string >> >> } >> >> Division's plenty more expensive than assigning a constant, >> especially on platforms that lack hardware FP division. >> >> David >> >> On 2013-06-07, at 2:03 AM, huizhe wang wrote: >> >>> Hi Aleksej, >>> >>> According to XPath spec, both positive and negative zero are >>> converted to the string 0, so it seems doesn't matter. But if you >>> want to detect the negative zero, you may do the following: >>> if (d == 0.0 && 1/d < 0.0) { >>> d=0.0 >>> } >>> >>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >>> >>> -Joe >> > From victor2 at ukr.net Fri Jun 7 20:42:15 2013 From: victor2 at ukr.net (Victor Polischuk) Date: Fri, 07 Jun 2013 23:42:15 +0300 Subject: =?UTF-8?B?UmU6IEluZWZmaWNpZW50IHVzZSBTdHJpbmdCdWZmZXIgb3IgU3RyaW5n?= =?UTF-8?B?QnVpbGRlcltPcHRpbWl6YXRpb258Y2xlYW4tdXBdCXtQYWNrYWdlOiBj?= =?UTF-8?B?b24uc3VuLiAqIGphdmEubGFuZyp9?= In-Reply-To: References: Message-ID: <61321.1370637735.2165610404893949952@ffe10.ukr.net> Excuse me for asking something stupid but do empty appends in "com.sun.tools.hat.internal.model.JavaValueArray" make any sense? result.append("").append(val); //Victor --- Original message --- From: "Ot?vio Gon?alves de Santana" Date: 7 June 2013, 16:20:02 > Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] > > The string addition in the parameter will create another string buffer, > append all the components, then convert that to a string so the you can be > appended to your string buffer. > > So I replace this: > > sb.append(" xxx: [" + getXXX() + "]\n"); > > for this: > > sb.append(" xxx: [").append(getXXX()).append("]\n"); > > The classes are: > > -- com.sun > com.sun.tools.hat.internal.model.JavaValueArray > com.sun.jmx.snmp.IPAcl.NetMaskImpl > com.sun.jndi.ldap.sasl.DefaultCallbackHandler > com.sun.media.sound.WaveExtensibleFileReader > com.sun.org.apache.xml.internal.security.encryption.XMLCipher > com.sun.org.apache.xml.internal.security.utils.RFC2253Parser > com.sun.security.sasl.CramMD5Base > com.sun.security.sasl.digest.DigestMD5Base > com.sun.tools.example.debug.gui.ContextManager > com.sun.tools.jdi.VirtualMachineImpl > > -- java.lang > java.lang.invoke.LambdaForm > > > The diff bellow: > > > diff --git > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > @@ -338,10 +338,10 @@ > if (classpath.isEmpty()) { > String envcp = System.getProperty("env.class.path"); > if ((envcp != null) && (envcp.length() > 0)) { > - munged.append(" -classpath " + envcp); > + munged.append(" -classpath ").append(envcp); > } > } else { > - munged.append(" -classpath " + classpath.asString()); > + munged.append(" -classpath ").append(classpath.asString()); > } > return munged.toString(); > } else { > > > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > @@ -199,8 +199,7 @@ > > for (i = 0; i < digest.length; i++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0" + > - Integer.toHexString(digest[i] & 0x000000ff)); > + > digestString.append("0").append(Integer.toHexString(digest[i] & > 0x000000ff)); > } else { > digestString.append( > Integer.toHexString(digest[i] & 0x000000ff)); > > > > > diff --git > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > @@ -90,7 +90,7 @@ > if (selected == -1) { > StringBuffer allChoices = new StringBuffer(); > for (int j = 0; j < choices.length; j++) { > - allChoices.append(choices[j] + ","); > + allChoices.append(choices[j]).append(','); > } > throw new IOException("Cannot match " + > "'java.naming.security.sasl.realm' > property value, '" + > > > > > diff --git > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > @@ -391,7 +391,7 @@ > > for (int i = 0; i < digest.length; i ++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0"+ > + digestString.append("0").append( > Integer.toHexString(digest[i] & 0x000000ff)); > } else { > digestString.append( > > > > > diff --git > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > @@ -386,37 +386,37 @@ > } > case 'B': { > int val = 0xFF & byteAt(i, value); > - result.append("0x" + Integer.toString(val, 16)); > + result.append("0x").append(Integer.toString(val, > 16)); > i++; > break; > } > case 'S': { > short val = shortAt(i, value); > i += 2; > - result.append("" + val); > + result.append("").append(val); > break; > } > case 'I': { > int val = intAt(i, value); > i += 4; > - result.append("" + val); > + result.append("").append( val); > break; > } > case 'J': { // long > long val = longAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > case 'F': { > float val = floatAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 4; > break; > } > case 'D': { // double > double val = doubleAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > > > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > @@ -65,7 +65,7 @@ > "extractSubNet", "BINARY ARRAY :"); > StringBuffer buff = new StringBuffer(); > for(int i =0; i < addrLength; i++) { > - buff.append((b[i] &0xFF) +":"); > + buff.append((b[i] &0xFF)).append(":"); > } > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > "extractSubNet", buff.toString()); > > > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > @@ -98,7 +98,7 @@ > l += countQuotes(_DN, j, k); > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); > > i = k + 1; > l = 0; > @@ -131,8 +131,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > - > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > i = k + 1; > l = 0; > } > @@ -386,7 +385,7 @@ > int k; > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > - sb.append(trim(string.substring(i, k)) + "\\ "); > + sb.append(trim(string.substring(i, k))).append("\\ "); > > i = k + 3; > } > @@ -436,7 +435,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(trim(str.substring(i, k)) + replace); > + sb.append(trim(str.substring(i, k))).append(replace); > > i = k + 1; > l = 0; > > > > > diff --git > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > @@ -338,10 +338,10 @@ > if (classpath.isEmpty()) { > String envcp = System.getProperty("env.class.path"); > if ((envcp != null) && (envcp.length() > 0)) { > - munged.append(" -classpath " + envcp); > + munged.append(" -classpath ").append(envcp); > } > } else { > - munged.append(" -classpath " + classpath.asString()); > + munged.append(" -classpath ").append(classpath.asString()); > } > return munged.toString(); > } else { > > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > @@ -199,8 +199,7 @@ > > for (i = 0; i < digest.length; i++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0" + > - Integer.toHexString(digest[i] & 0x000000ff)); > + > digestString.append("0").append(Integer.toHexString(digest[i] & > 0x000000ff)); > } else { > digestString.append( > Integer.toHexString(digest[i] & 0x000000ff)); > > > > diff --git > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > @@ -90,7 +90,7 @@ > if (selected == -1) { > StringBuffer allChoices = new StringBuffer(); > for (int j = 0; j < choices.length; j++) { > - allChoices.append(choices[j] + ","); > + allChoices.append(choices[j]).append(','); > } > throw new IOException("Cannot match " + > "'java.naming.security.sasl.realm' > property value, '" + > > > > diff --git > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > @@ -391,7 +391,7 @@ > > for (int i = 0; i < digest.length; i ++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0"+ > + digestString.append("0").append( > Integer.toHexString(digest[i] & 0x000000ff)); > } else { > digestString.append( > > > > diff --git > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > @@ -386,37 +386,37 @@ > } > case 'B': { > int val = 0xFF & byteAt(i, value); > - result.append("0x" + Integer.toString(val, 16)); > + result.append("0x").append(Integer.toString(val, > 16)); > i++; > break; > } > case 'S': { > short val = shortAt(i, value); > i += 2; > - result.append("" + val); > + result.append("").append(val); > break; > } > case 'I': { > int val = intAt(i, value); > i += 4; > - result.append("" + val); > + result.append("").append( val); > break; > } > case 'J': { // long > long val = longAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > case 'F': { > float val = floatAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 4; > break; > } > case 'D': { // double > double val = doubleAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > @@ -65,7 +65,7 @@ > "extractSubNet", "BINARY ARRAY :"); > StringBuffer buff = new StringBuffer(); > for(int i =0; i < addrLength; i++) { > - buff.append((b[i] &0xFF) +":"); > + buff.append((b[i] &0xFF)).append(":"); > } > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > "extractSubNet", buff.toString()); > > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > @@ -98,7 +98,7 @@ > l += countQuotes(_DN, j, k); > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); > > i = k + 1; > l = 0; > @@ -131,8 +131,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > - > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > i = k + 1; > l = 0; > } > @@ -386,7 +385,7 @@ > int k; > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > - sb.append(trim(string.substring(i, k)) + "\\ "); > + sb.append(trim(string.substring(i, k))).append("\\ "); > > i = k + 3; > } > @@ -436,7 +435,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(trim(str.substring(i, k)) + replace); > + sb.append(trim(str.substring(i, k))).append(replace); > > i = k + 1; > l = 0; > > > > diff --git > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > @@ -338,10 +338,10 @@ > if (classpath.isEmpty()) { > String envcp = System.getProperty("env.class.path"); > if ((envcp != null) && (envcp.length() > 0)) { > - munged.append(" -classpath " + envcp); > + munged.append(" -classpath ").append(envcp); > } > } else { > - munged.append(" -classpath " + classpath.asString()); > + munged.append(" -classpath ").append(classpath.asString()); > } > return munged.toString(); > } else { > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > @@ -199,8 +199,7 @@ > > for (i = 0; i < digest.length; i++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0" + > - Integer.toHexString(digest[i] & 0x000000ff)); > + > digestString.append("0").append(Integer.toHexString(digest[i] & > 0x000000ff)); > } else { > digestString.append( > Integer.toHexString(digest[i] & 0x000000ff)); > > > diff --git > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > @@ -90,7 +90,7 @@ > if (selected == -1) { > StringBuffer allChoices = new StringBuffer(); > for (int j = 0; j < choices.length; j++) { > - allChoices.append(choices[j] + ","); > + allChoices.append(choices[j]).append(','); > } > throw new IOException("Cannot match " + > "'java.naming.security.sasl.realm' > property value, '" + > > > diff --git > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > @@ -391,7 +391,7 @@ > > for (int i = 0; i < digest.length; i ++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0"+ > + digestString.append("0").append( > Integer.toHexString(digest[i] & 0x000000ff)); > } else { > digestString.append( > > > diff --git > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > @@ -386,37 +386,37 @@ > } > case 'B': { > int val = 0xFF & byteAt(i, value); > - result.append("0x" + Integer.toString(val, 16)); > + result.append("0x").append(Integer.toString(val, > 16)); > i++; > break; > } > case 'S': { > short val = shortAt(i, value); > i += 2; > - result.append("" + val); > + result.append("").append(val); > break; > } > case 'I': { > int val = intAt(i, value); > i += 4; > - result.append("" + val); > + result.append("").append( val); > break; > } > case 'J': { // long > long val = longAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > case 'F': { > float val = floatAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 4; > break; > } > case 'D': { // double > double val = doubleAt(i, value); > - result.append("" + val); > + result.append("").append(val); > i += 8; > break; > } > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > @@ -65,7 +65,7 @@ > "extractSubNet", "BINARY ARRAY :"); > StringBuffer buff = new StringBuffer(); > for(int i =0; i < addrLength; i++) { > - buff.append((b[i] &0xFF) +":"); > + buff.append((b[i] &0xFF)).append(":"); > } > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > "extractSubNet", buff.toString()); > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > @@ -98,7 +98,7 @@ > l += countQuotes(_DN, j, k); > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); > > i = k + 1; > l = 0; > @@ -131,8 +131,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > - > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > i = k + 1; > l = 0; > } > @@ -386,7 +385,7 @@ > int k; > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > - sb.append(trim(string.substring(i, k)) + "\\ "); > + sb.append(trim(string.substring(i, k))).append("\\ "); > > i = k + 3; > } > @@ -436,7 +435,7 @@ > l += countQuotes(str, j, k); > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > - sb.append(trim(str.substring(i, k)) + replace); > + sb.append(trim(str.substring(i, k))).append(replace); > > i = k + 1; > l = 0; > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > @@ -881,10 +881,10 @@ > } else if (tag == JDWP.TypeTag.ARRAY) { > sb.append("ArrayType"); > } else { > - sb.append("UNKNOWN TAG: " + tag); > + sb.append("UNKNOWN TAG: ").append(tag); > } > if (signature != null) { > - sb.append(", signature='" + signature + "'"); > + sb.append(", signature='").append(signature).append("'"); > } > sb.append(", id=" + id); > vm.printTrace(sb.toString()); > > > diff --git > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > @@ -167,9 +167,9 @@ > for (int i = 0; i < allchannelnames.length; i++) { > if ((channelmask & m) != 0L) { > if (i < channelnames.length) { > - sb.append(channelnames[i] + " "); > + sb.append(channelnames[i]).append(" "); > } else { > - sb.append(allchannelnames[i] + " "); > + sb.append(allchannelnames[i]).append(" "); > } > } > m *= 2L; > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > @@ -1932,7 +1932,7 @@ > StringBuffer sb; > > sb = new StringBuffer(); > - sb.append(" encoding=\"UTF-8\"?><"+tagname); > + sb.append(" encoding=\"UTF-8\"?><").append(tagname); > > // Run through each node up to the document node > and find any > // xmlns: nodes > > > > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > @@ -881,10 +881,10 @@ > } else if (tag == JDWP.TypeTag.ARRAY) { > sb.append("ArrayType"); > } else { > - sb.append("UNKNOWN TAG: " + tag); > + sb.append("UNKNOWN TAG: ").append(tag); > } > if (signature != null) { > - sb.append(", signature='" + signature + "'"); > + sb.append(", signature='").append(signature).append("'"); > } > sb.append(", id=" + id); > vm.printTrace(sb.toString()); > > > > diff --git > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > @@ -167,9 +167,9 @@ > for (int i = 0; i < allchannelnames.length; i++) { > if ((channelmask & m) != 0L) { > if (i < channelnames.length) { > - sb.append(channelnames[i] + " "); > + sb.append(channelnames[i]).append(" "); > } else { > - sb.append(allchannelnames[i] + " "); > + sb.append(allchannelnames[i]).append(" "); > } > } > m *= 2L; > > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > @@ -1932,7 +1932,7 @@ > StringBuffer sb; > > sb = new StringBuffer(); > - sb.append(" encoding=\"UTF-8\"?><"+tagname); > + sb.append(" encoding=\"UTF-8\"?><").append(tagname); > > // Run through each node up to the document node > and find any > // xmlns: nodes > > > > > > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > @@ -881,10 +881,10 @@ > } else if (tag == JDWP.TypeTag.ARRAY) { > sb.append("ArrayType"); > } else { > - sb.append("UNKNOWN TAG: " + tag); > + sb.append("UNKNOWN TAG: ").append(tag); > } > if (signature != null) { > - sb.append(", signature='" + signature + "'"); > + sb.append(", signature='").append(signature).append("'"); > } > sb.append(", id=" + id); > vm.printTrace(sb.toString()); > > > > > diff --git > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > @@ -167,9 +167,9 @@ > for (int i = 0; i < allchannelnames.length; i++) { > if ((channelmask & m) != 0L) { > if (i < channelnames.length) { > - sb.append(channelnames[i] + " "); > + sb.append(channelnames[i]).append(" "); > } else { > - sb.append(allchannelnames[i] + " "); > + sb.append(allchannelnames[i]).append(" "); > } > } > m *= 2L; > > > > > diff --git > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > --- > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > +++ > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > @@ -1932,7 +1932,7 @@ > StringBuffer sb; > > sb = new StringBuffer(); > - sb.append(" encoding=\"UTF-8\"?><"+tagname); > + sb.append(" encoding=\"UTF-8\"?><").append(tagname); > > // Run through each node up to the document node > and find any > // xmlns: nodes > > > > > > -- java_lang > > > diff --git a/src/share/classes/java/lang/invoke/LambdaForm.java > b/src/share/classes/java/lang/invoke/LambdaForm.java > --- a/src/share/classes/java/lang/invoke/LambdaForm.java > +++ b/src/share/classes/java/lang/invoke/LambdaForm.java > @@ -708,7 +708,7 @@ > } > > public String toString() { > - StringBuilder buf = new StringBuilder(debugName+"=Lambda("); > + StringBuilder buf = new > StringBuilder(debugName).append("=Lambda("); > for (int i = 0; i < names.length; i++) { > if (i == arity) buf.append(")=>{"); > Name n = names[i]; > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 From xueming.shen at oracle.com Fri Jun 7 20:53:41 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 07 Jun 2013 20:53:41 +0000 Subject: hg: jdk8/tl/jdk: 8015728: (zipfs) demo/zipfs/basic.sh failing Message-ID: <20130607205415.25998480B1@hg.openjdk.java.net> Changeset: aed2ad905da6 Author: sherman Date: 2013-06-07 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aed2ad905da6 8015728: (zipfs) demo/zipfs/basic.sh failing Summary: to return the correct loc entry size from wirteLOC(); Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From martinrb at google.com Fri Jun 7 21:51:47 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 7 Jun 2013 14:51:47 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: is denigrated in favor of {@code ? --- "specified navigable set" ? + * The returned navigable set will be serializable if the specified sorted set + * is serializable. --- Y U NO throw UOE? + @Override + public Entry pollFirstEntry() { + Entry entry = (Entry) nm.pollFirstEntry(); + return (null == entry) ? null : new UnmodifiableEntrySet.UnmodifiableEntry(entry); + } --- navigable set? + * Returns a synchronized (thread-safe) sorted set backed by the specified + * navigable set. In order to guarantee serial access, it is critical that On Fri, Jun 7, 2013 at 10:58 AM, Mike Duigou wrote: > Hello all; > > I've incorporated feedback from previous rounds and expect to finalize > this addition soon. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ > > Any review feedback or suggestions of additional tests welcome. > > Thanks, > > Mike > > > From joe.darcy at oracle.com Fri Jun 7 22:08:06 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 07 Jun 2013 15:08:06 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: <51B259C6.80004@oracle.com> On 6/7/2013 2:51 PM, Martin Buchholz wrote: > is denigrated in favor of {@code ? It is by me anyway! -Joe From otaviojava at java.net Fri Jun 7 22:16:27 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 19:16:27 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: con.sun. * java.lang*} In-Reply-To: <61321.1370637735.2165610404893949952@ffe10.ukr.net> References: <61321.1370637735.2165610404893949952@ffe10.ukr.net> Message-ID: Yes, I think you are right. I did one more refactoring in this packages. diff --git a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java --- a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java +++ b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java @@ -338,10 +338,10 @@ if (classpath.isEmpty()) { String envcp = System.getProperty("env.class.path"); if ((envcp != null) && (envcp.length() > 0)) { - munged.append(" -classpath " + envcp); + munged.append(" -classpath ").append(envcp); } } else { - munged.append(" -classpath " + classpath.asString()); + munged.append(" -classpath ").append(classpath.asString()); } return munged.toString(); } else { diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java b/src/share/classes/com/sun/security/sasl/CramMD5Base.java --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java @@ -199,8 +199,7 @@ for (i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + - Integer.toHexString(digest[i] & 0x000000ff)); + digestString.append('0').append(Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( Integer.toHexString(digest[i] & 0x000000ff)); diff --git a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java --- a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java +++ b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java @@ -90,7 +90,7 @@ if (selected == -1) { StringBuffer allChoices = new StringBuffer(); for (int j = 0; j < choices.length; j++) { - allChoices.append(choices[j] + ","); + allChoices.append(choices[j]).append(','); } throw new IOException("Cannot match " + "'java.naming.security.sasl.realm' property value, '" + diff --git a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java @@ -391,7 +391,7 @@ for (int i = 0; i < digest.length; i ++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0"+ + digestString.append('0').append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java --- a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java +++ b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java @@ -386,37 +386,37 @@ } case 'B': { int val = 0xFF & byteAt(i, value); - result.append("0x" + Integer.toString(val, 16)); + result.append("0x").append(Integer.toString(val, 16)); i++; break; } case 'S': { short val = shortAt(i, value); i += 2; - result.append("" + val); + result.append(val); break; } case 'I': { int val = intAt(i, value); i += 4; - result.append("" + val); + result.append( val); break; } case 'J': { // long long val = longAt(i, value); - result.append("" + val); + result.append(val); i += 8; break; } case 'F': { float val = floatAt(i, value); - result.append("" + val); + result.append(val); i += 4; break; } case 'D': { // double double val = doubleAt(i, value); - result.append("" + val); + result.append(val); i += 8; break; } diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java @@ -65,7 +65,7 @@ "extractSubNet", "BINARY ARRAY :"); StringBuffer buff = new StringBuffer(); for(int i =0; i < addrLength; i++) { - buff.append((b[i] &0xFF) +":"); + buff.append((b[i] &0xFF)).append(':'); } SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), "extractSubNet", buff.toString()); diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java @@ -98,7 +98,7 @@ l += countQuotes(_DN, j, k); if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); + sb.append(parseRDN(_DN.substring(i, k).trim())).append(','); i = k + 1; l = 0; @@ -131,8 +131,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); - + sb.append(parseATAV(trim(str.substring(i, k)))).append('+'); i = k + 1; l = 0; } @@ -386,7 +385,7 @@ int k; for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { - sb.append(trim(string.substring(i, k)) + "\\ "); + sb.append(trim(string.substring(i, k))).append("\\ "); i = k + 3; } @@ -436,7 +435,7 @@ l += countQuotes(str, j, k); if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { - sb.append(trim(str.substring(i, k)) + replace); + sb.append(trim(str.substring(i, k))).append(replace); i = k + 1; l = 0; diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java @@ -881,10 +881,10 @@ } else if (tag == JDWP.TypeTag.ARRAY) { sb.append("ArrayType"); } else { - sb.append("UNKNOWN TAG: " + tag); + sb.append("UNKNOWN TAG: ").append(tag); } if (signature != null) { - sb.append(", signature='" + signature + "'"); + sb.append(", signature='").append(signature).append("'"); } sb.append(", id=" + id); vm.printTrace(sb.toString()); diff --git a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java @@ -167,9 +167,9 @@ for (int i = 0; i < allchannelnames.length; i++) { if ((channelmask & m) != 0L) { if (i < channelnames.length) { - sb.append(channelnames[i] + " "); + sb.append(channelnames[i]).append(' '); } else { - sb.append(allchannelnames[i] + " "); + sb.append(allchannelnames[i]).append(' '); } } m *= 2L; diff --git a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java --- a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java +++ b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java @@ -1932,7 +1932,7 @@ StringBuffer sb; sb = new StringBuffer(); - sb.append("<"+tagname); + sb.append("<").append(tagname); // Run through each node up to the document node and find any // xmlns: nodes On Fri, Jun 7, 2013 at 5:42 PM, Victor Polischuk wrote: > Excuse me for asking something stupid but do empty appends in > "com.sun.tools.hat.internal.model.JavaValueArray" make any sense? > > result.append("").append(val); > > //Victor > > --- Original message --- > From: "Ot?vio Gon?alves de Santana" > Date: 7 June 2013, 16:20:02 > > > > Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] > > > > The string addition in the parameter will create another string buffer, > > append all the components, then convert that to a string so the you can > be > > appended to your string buffer. > > > > So I replace this: > > > > sb.append(" xxx: [" + getXXX() + "]\n"); > > > > for this: > > > > sb.append(" xxx: [").append(getXXX()).append("]\n"); > > > > The classes are: > > > > -- com.sun > > com.sun.tools.hat.internal.model.JavaValueArray > > com.sun.jmx.snmp.IPAcl.NetMaskImpl > > com.sun.jndi.ldap.sasl.DefaultCallbackHandler > > com.sun.media.sound.WaveExtensibleFileReader > > com.sun.org.apache.xml.internal.security.encryption.XMLCipher > > com.sun.org.apache.xml.internal.security.utils.RFC2253Parser > > com.sun.security.sasl.CramMD5Base > > com.sun.security.sasl.digest.DigestMD5Base > > com.sun.tools.example.debug.gui.ContextManager > > com.sun.tools.jdi.VirtualMachineImpl > > > > -- java.lang > > java.lang.invoke.LambdaForm > > > > > > The diff bellow: > > > > > > diff --git > > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > --- > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > +++ > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > @@ -338,10 +338,10 @@ > > if (classpath.isEmpty()) { > > String envcp = System.getProperty("env.class.path"); > > if ((envcp != null) && (envcp.length() > 0)) { > > - munged.append(" -classpath " + envcp); > > + munged.append(" -classpath ").append(envcp); > > } > > } else { > > - munged.append(" -classpath " + classpath.asString()); > > + munged.append(" -classpath > ").append(classpath.asString()); > > } > > return munged.toString(); > > } else { > > > > > > > > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > @@ -199,8 +199,7 @@ > > > > for (i = 0; i < digest.length; i++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0" + > > - Integer.toHexString(digest[i] & 0x000000ff)); > > + > > digestString.append("0").append(Integer.toHexString(digest[i] & > > 0x000000ff)); > > } else { > > digestString.append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > > > > > > > > > diff --git > > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > --- > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > +++ > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > @@ -90,7 +90,7 @@ > > if (selected == -1) { > > StringBuffer allChoices = new StringBuffer(); > > for (int j = 0; j < choices.length; j++) { > > - allChoices.append(choices[j] + ","); > > + > allChoices.append(choices[j]).append(','); > > } > > throw new IOException("Cannot match " + > > "'java.naming.security.sasl.realm' > > property value, '" + > > > > > > > > > > diff --git > > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > @@ -391,7 +391,7 @@ > > > > for (int i = 0; i < digest.length; i ++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0"+ > > + digestString.append("0").append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > } else { > > digestString.append( > > > > > > > > > > diff --git > > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > --- > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > +++ > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > @@ -386,37 +386,37 @@ > > } > > case 'B': { > > int val = 0xFF & byteAt(i, value); > > - result.append("0x" + Integer.toString(val, 16)); > > + result.append("0x").append(Integer.toString(val, > > 16)); > > i++; > > break; > > } > > case 'S': { > > short val = shortAt(i, value); > > i += 2; > > - result.append("" + val); > > + result.append("").append(val); > > break; > > } > > case 'I': { > > int val = intAt(i, value); > > i += 4; > > - result.append("" + val); > > + result.append("").append( val); > > break; > > } > > case 'J': { // long > > long val = longAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > case 'F': { > > float val = floatAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 4; > > break; > > } > > case 'D': { // double > > double val = doubleAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > > > > > > > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > @@ -65,7 +65,7 @@ > > "extractSubNet", "BINARY ARRAY :"); > > StringBuffer buff = new StringBuffer(); > > for(int i =0; i < addrLength; i++) { > > - buff.append((b[i] &0xFF) +":"); > > + buff.append((b[i] &0xFF)).append(":"); > > } > > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > > "extractSubNet", buff.toString()); > > > > > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > @@ -98,7 +98,7 @@ > > l += countQuotes(_DN, j, k); > > > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > > + sb.append(parseRDN(_DN.substring(i, > k).trim())).append(','); > > > > i = k + 1; > > l = 0; > > @@ -131,8 +131,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > > - > > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > > i = k + 1; > > l = 0; > > } > > @@ -386,7 +385,7 @@ > > int k; > > > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > > - sb.append(trim(string.substring(i, k)) + "\\ "); > > + sb.append(trim(string.substring(i, k))).append("\\ "); > > > > i = k + 3; > > } > > @@ -436,7 +435,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(trim(str.substring(i, k)) + replace); > > + sb.append(trim(str.substring(i, k))).append(replace); > > > > i = k + 1; > > l = 0; > > > > > > > > > > diff --git > > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > --- > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > +++ > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > @@ -338,10 +338,10 @@ > > if (classpath.isEmpty()) { > > String envcp = System.getProperty("env.class.path"); > > if ((envcp != null) && (envcp.length() > 0)) { > > - munged.append(" -classpath " + envcp); > > + munged.append(" -classpath ").append(envcp); > > } > > } else { > > - munged.append(" -classpath " + classpath.asString()); > > + munged.append(" -classpath > ").append(classpath.asString()); > > } > > return munged.toString(); > > } else { > > > > > > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > @@ -199,8 +199,7 @@ > > > > for (i = 0; i < digest.length; i++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0" + > > - Integer.toHexString(digest[i] & 0x000000ff)); > > + > > digestString.append("0").append(Integer.toHexString(digest[i] & > > 0x000000ff)); > > } else { > > digestString.append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > > > > > > > diff --git > > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > --- > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > +++ > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > @@ -90,7 +90,7 @@ > > if (selected == -1) { > > StringBuffer allChoices = new StringBuffer(); > > for (int j = 0; j < choices.length; j++) { > > - allChoices.append(choices[j] + ","); > > + > allChoices.append(choices[j]).append(','); > > } > > throw new IOException("Cannot match " + > > "'java.naming.security.sasl.realm' > > property value, '" + > > > > > > > > diff --git > > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > @@ -391,7 +391,7 @@ > > > > for (int i = 0; i < digest.length; i ++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0"+ > > + digestString.append("0").append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > } else { > > digestString.append( > > > > > > > > diff --git > > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > --- > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > +++ > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > @@ -386,37 +386,37 @@ > > } > > case 'B': { > > int val = 0xFF & byteAt(i, value); > > - result.append("0x" + Integer.toString(val, 16)); > > + result.append("0x").append(Integer.toString(val, > > 16)); > > i++; > > break; > > } > > case 'S': { > > short val = shortAt(i, value); > > i += 2; > > - result.append("" + val); > > + result.append("").append(val); > > break; > > } > > case 'I': { > > int val = intAt(i, value); > > i += 4; > > - result.append("" + val); > > + result.append("").append( val); > > break; > > } > > case 'J': { // long > > long val = longAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > case 'F': { > > float val = floatAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 4; > > break; > > } > > case 'D': { // double > > double val = doubleAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > > > > > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > @@ -65,7 +65,7 @@ > > "extractSubNet", "BINARY ARRAY :"); > > StringBuffer buff = new StringBuffer(); > > for(int i =0; i < addrLength; i++) { > > - buff.append((b[i] &0xFF) +":"); > > + buff.append((b[i] &0xFF)).append(":"); > > } > > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > > "extractSubNet", buff.toString()); > > > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > @@ -98,7 +98,7 @@ > > l += countQuotes(_DN, j, k); > > > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > > + sb.append(parseRDN(_DN.substring(i, > k).trim())).append(','); > > > > i = k + 1; > > l = 0; > > @@ -131,8 +131,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > > - > > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > > i = k + 1; > > l = 0; > > } > > @@ -386,7 +385,7 @@ > > int k; > > > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > > - sb.append(trim(string.substring(i, k)) + "\\ "); > > + sb.append(trim(string.substring(i, k))).append("\\ "); > > > > i = k + 3; > > } > > @@ -436,7 +435,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(trim(str.substring(i, k)) + replace); > > + sb.append(trim(str.substring(i, k))).append(replace); > > > > i = k + 1; > > l = 0; > > > > > > > > diff --git > > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > --- > a/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > +++ > b/src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java > > @@ -338,10 +338,10 @@ > > if (classpath.isEmpty()) { > > String envcp = System.getProperty("env.class.path"); > > if ((envcp != null) && (envcp.length() > 0)) { > > - munged.append(" -classpath " + envcp); > > + munged.append(" -classpath ").append(envcp); > > } > > } else { > > - munged.append(" -classpath " + classpath.asString()); > > + munged.append(" -classpath > ").append(classpath.asString()); > > } > > return munged.toString(); > > } else { > > > > > > diff --git a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/CramMD5Base.java > > @@ -199,8 +199,7 @@ > > > > for (i = 0; i < digest.length; i++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0" + > > - Integer.toHexString(digest[i] & 0x000000ff)); > > + > > digestString.append("0").append(Integer.toHexString(digest[i] & > > 0x000000ff)); > > } else { > > digestString.append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > > > > > diff --git > > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > --- > a/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > +++ > b/src/share/classes/com/sun/jndi/ldap/sasl/DefaultCallbackHandler.java > > @@ -90,7 +90,7 @@ > > if (selected == -1) { > > StringBuffer allChoices = new StringBuffer(); > > for (int j = 0; j < choices.length; j++) { > > - allChoices.append(choices[j] + ","); > > + > allChoices.append(choices[j]).append(','); > > } > > throw new IOException("Cannot match " + > > "'java.naming.security.sasl.realm' > > property value, '" + > > > > > > diff --git > > a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > --- a/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > +++ b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java > > @@ -391,7 +391,7 @@ > > > > for (int i = 0; i < digest.length; i ++) { > > if ((digest[i] & 0x000000ff) < 0x10) { > > - digestString.append("0"+ > > + digestString.append("0").append( > > Integer.toHexString(digest[i] & 0x000000ff)); > > } else { > > digestString.append( > > > > > > diff --git > > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > --- > a/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > +++ > b/src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java > > @@ -386,37 +386,37 @@ > > } > > case 'B': { > > int val = 0xFF & byteAt(i, value); > > - result.append("0x" + Integer.toString(val, 16)); > > + result.append("0x").append(Integer.toString(val, > > 16)); > > i++; > > break; > > } > > case 'S': { > > short val = shortAt(i, value); > > i += 2; > > - result.append("" + val); > > + result.append("").append(val); > > break; > > } > > case 'I': { > > int val = intAt(i, value); > > i += 4; > > - result.append("" + val); > > + result.append("").append( val); > > break; > > } > > case 'J': { // long > > long val = longAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > case 'F': { > > float val = floatAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 4; > > break; > > } > > case 'D': { // double > > double val = doubleAt(i, value); > > - result.append("" + val); > > + result.append("").append(val); > > i += 8; > > break; > > } > > > > > > diff --git a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > --- a/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > +++ b/src/share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java > > @@ -65,7 +65,7 @@ > > "extractSubNet", "BINARY ARRAY :"); > > StringBuffer buff = new StringBuffer(); > > for(int i =0; i < addrLength; i++) { > > - buff.append((b[i] &0xFF) +":"); > > + buff.append((b[i] &0xFF)).append(":"); > > } > > SNMP_LOGGER.logp(Level.FINEST, NetMaskImpl.class.getName(), > > "extractSubNet", buff.toString()); > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java > > @@ -98,7 +98,7 @@ > > l += countQuotes(_DN, j, k); > > > > if ((k > 0) && (_DN.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseRDN(_DN.substring(i, k).trim()) + ","); > > + sb.append(parseRDN(_DN.substring(i, > k).trim())).append(','); > > > > i = k + 1; > > l = 0; > > @@ -131,8 +131,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(parseATAV(trim(str.substring(i, k))) + "+"); > > - > > + sb.append(parseATAV(trim(str.substring(i, k)))).append("+"); > > i = k + 1; > > l = 0; > > } > > @@ -386,7 +385,7 @@ > > int k; > > > > for (int j = 0; (k = string.indexOf("\\20", j)) >= 0; j = k + 3) { > > - sb.append(trim(string.substring(i, k)) + "\\ "); > > + sb.append(trim(string.substring(i, k))).append("\\ "); > > > > i = k + 3; > > } > > @@ -436,7 +435,7 @@ > > l += countQuotes(str, j, k); > > > > if ((k > 0) && (str.charAt(k - 1) != '\\') && (l % 2) != 1) { > > - sb.append(trim(str.substring(i, k)) + replace); > > + sb.append(trim(str.substring(i, k))).append(replace); > > > > i = k + 1; > > l = 0; > > > > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > @@ -881,10 +881,10 @@ > > } else if (tag == JDWP.TypeTag.ARRAY) { > > sb.append("ArrayType"); > > } else { > > - sb.append("UNKNOWN TAG: " + tag); > > + sb.append("UNKNOWN TAG: ").append(tag); > > } > > if (signature != null) { > > - sb.append(", signature='" + signature + "'"); > > + sb.append(", > signature='").append(signature).append("'"); > > } > > sb.append(", id=" + id); > > vm.printTrace(sb.toString()); > > > > > > diff --git > > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > @@ -167,9 +167,9 @@ > > for (int i = 0; i < allchannelnames.length; i++) { > > if ((channelmask & m) != 0L) { > > if (i < channelnames.length) { > > - sb.append(channelnames[i] + " "); > > + sb.append(channelnames[i]).append(" "); > > } else { > > - sb.append(allchannelnames[i] + " "); > > + sb.append(allchannelnames[i]).append(" "); > > } > > } > > m *= 2L; > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > @@ -1932,7 +1932,7 @@ > > StringBuffer sb; > > > > sb = new StringBuffer(); > > - sb.append(" > encoding=\"UTF-8\"?><"+tagname); > > + sb.append(" > encoding=\"UTF-8\"?><").append(tagname); > > > > // Run through each node up to the document node > > and find any > > // xmlns: nodes > > > > > > > > > > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > @@ -881,10 +881,10 @@ > > } else if (tag == JDWP.TypeTag.ARRAY) { > > sb.append("ArrayType"); > > } else { > > - sb.append("UNKNOWN TAG: " + tag); > > + sb.append("UNKNOWN TAG: ").append(tag); > > } > > if (signature != null) { > > - sb.append(", signature='" + signature + "'"); > > + sb.append(", > signature='").append(signature).append("'"); > > } > > sb.append(", id=" + id); > > vm.printTrace(sb.toString()); > > > > > > > > diff --git > > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > @@ -167,9 +167,9 @@ > > for (int i = 0; i < allchannelnames.length; i++) { > > if ((channelmask & m) != 0L) { > > if (i < channelnames.length) { > > - sb.append(channelnames[i] + " "); > > + sb.append(channelnames[i]).append(" "); > > } else { > > - sb.append(allchannelnames[i] + " "); > > + sb.append(allchannelnames[i]).append(" "); > > } > > } > > m *= 2L; > > > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > @@ -1932,7 +1932,7 @@ > > StringBuffer sb; > > > > sb = new StringBuffer(); > > - sb.append(" > encoding=\"UTF-8\"?><"+tagname); > > + sb.append(" > encoding=\"UTF-8\"?><").append(tagname); > > > > // Run through each node up to the document node > > and find any > > // xmlns: nodes > > > > > > > > > > > > > > > > diff --git a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > --- a/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > +++ b/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java > > @@ -881,10 +881,10 @@ > > } else if (tag == JDWP.TypeTag.ARRAY) { > > sb.append("ArrayType"); > > } else { > > - sb.append("UNKNOWN TAG: " + tag); > > + sb.append("UNKNOWN TAG: ").append(tag); > > } > > if (signature != null) { > > - sb.append(", signature='" + signature + "'"); > > + sb.append(", > signature='").append(signature).append("'"); > > } > > sb.append(", id=" + id); > > vm.printTrace(sb.toString()); > > > > > > > > > > diff --git > > a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > --- a/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > +++ b/src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java > > @@ -167,9 +167,9 @@ > > for (int i = 0; i < allchannelnames.length; i++) { > > if ((channelmask & m) != 0L) { > > if (i < channelnames.length) { > > - sb.append(channelnames[i] + " "); > > + sb.append(channelnames[i]).append(" "); > > } else { > > - sb.append(allchannelnames[i] + " "); > > + sb.append(allchannelnames[i]).append(" "); > > } > > } > > m *= 2L; > > > > > > > > > > diff --git > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > --- > > > a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > +++ > > > b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java > > @@ -1932,7 +1932,7 @@ > > StringBuffer sb; > > > > sb = new StringBuffer(); > > - sb.append(" > encoding=\"UTF-8\"?><"+tagname); > > + sb.append(" > encoding=\"UTF-8\"?><").append(tagname); > > > > // Run through each node up to the document node > > and find any > > // xmlns: nodes > > > > > > > > > > > > -- java_lang > > > > > > diff --git a/src/share/classes/java/lang/invoke/LambdaForm.java > > b/src/share/classes/java/lang/invoke/LambdaForm.java > > --- a/src/share/classes/java/lang/invoke/LambdaForm.java > > +++ b/src/share/classes/java/lang/invoke/LambdaForm.java > > @@ -708,7 +708,7 @@ > > } > > > > public String toString() { > > - StringBuilder buf = new StringBuilder(debugName+"=Lambda("); > > + StringBuilder buf = new > > StringBuilder(debugName).append("=Lambda("); > > for (int i = 0; i < names.length; i++) { > > if (i == arity) buf.append(")=>{"); > > Name n = names[i]; > > > > > > > > > > > > > > -- > > Atenciosamente. > > > > Ot?vio Gon?alves de Santana > > > > blog: http://otaviosantana.blogspot.com.br/ > > twitter: http://twitter.com/otaviojava > > site: http://www.otaviojava.com.br > > (11) 98255-3513 > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From otaviojava at java.net Fri Jun 7 22:20:31 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 19:20:31 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: java. * without Swing} In-Reply-To: References: Message-ID: I did one more refactoring in this packages. diff --git a/src/share/classes/javax/management/openmbean/ArrayType.java b/src/share/classes/javax/management/openmbean/ArrayType.java --- a/src/share/classes/javax/management/openmbean/ArrayType.java +++ b/src/share/classes/javax/management/openmbean/ArrayType.java @@ -459,7 +459,7 @@ isPrimitiveArray = at.isPrimitiveArray(); } StringBuilder result = - new StringBuilder(dimension + "-dimension array of "); + new StringBuilder(dimension).append("-dimension array of "); final String elementClassName = elementType.getClassName(); if (isPrimitiveArray) { // Convert from wrapper type to primitive type diff --git a/src/share/classes/javax/sound/sampled/AudioFileFormat.java b/src/share/classes/javax/sound/sampled/AudioFileFormat.java --- a/src/share/classes/javax/sound/sampled/AudioFileFormat.java +++ b/src/share/classes/javax/sound/sampled/AudioFileFormat.java @@ -288,19 +288,20 @@ //$$fb2002-11-01: fix for 4672864: AudioFileFormat.toString() throws unexpected NullPointerException if (type != null) { - buf.append(type.toString() + " (." + type.getExtension() + ") file"); + buf.append(type.toString()).append(" (.").append(type.getExtension()).append(") file"); + } else { buf.append("unknown file format"); } if (byteLength != AudioSystem.NOT_SPECIFIED) { - buf.append(", byte length: " + byteLength); + buf.append(", byte length: ").append(byteLength); } - buf.append(", data format: " + format); + buf.append(", data format: ").append(format); if (frameLength != AudioSystem.NOT_SPECIFIED) { - buf.append(", frame length: " + frameLength); + buf.append(", frame length: ").append(frameLength); } return new String(buf); diff --git a/src/share/classes/javax/naming/directory/BasicAttribute.java b/src/share/classes/javax/naming/directory/BasicAttribute.java --- a/src/share/classes/javax/naming/directory/BasicAttribute.java +++ b/src/share/classes/javax/naming/directory/BasicAttribute.java @@ -211,7 +211,7 @@ * @return The non-null string representation of this attribute. */ public String toString() { - StringBuffer answer = new StringBuffer(attrID + ": "); + StringBuffer answer = new StringBuffer(attrID).append(": "); if (values.size() == 0) { answer.append("No values"); } else { diff --git a/src/share/classes/javax/naming/BinaryRefAddr.java b/src/share/classes/javax/naming/BinaryRefAddr.java --- a/src/share/classes/javax/naming/BinaryRefAddr.java +++ b/src/share/classes/javax/naming/BinaryRefAddr.java @@ -169,7 +169,7 @@ str.append("AddressContents: "); for (int i = 0; i= 32) str.append(" ...\n"); diff --git a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java --- a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java +++ b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java @@ -197,7 +197,7 @@ */ public String toString() { String ls = System.getProperty("line.separator", "\n"); - StringBuilder sb = new StringBuilder("JPEGQTable:"+ls); + StringBuilder sb = new StringBuilder("JPEGQTable:").append(ls); for (int i=0; i < qTable.length; i++) { if (i % 8 == 0) { sb.append('\t'); diff --git a/src/share/classes/javax/naming/NameImpl.java b/src/share/classes/javax/naming/NameImpl.java --- a/src/share/classes/javax/naming/NameImpl.java +++ b/src/share/classes/javax/naming/NameImpl.java @@ -170,7 +170,7 @@ endQuote = one ? syntaxEndQuote1 : syntaxEndQuote2; i += syntaxTypevalSeparator.length(); - answer.append(syntaxTypevalSeparator+beginQuote); // add back + answer.append(syntaxTypevalSeparator).append(beginQuote); // add back // consume string until matching quote for (i += beginQuote.length(); On Fri, Jun 7, 2013 at 10:25 AM, Ot?vio Gon?alves de Santana < otaviojava at java.net> wrote: > > The string addition in the parameter will create another string buffer, > append all the components, then convert that to a string so the you can be > appended to your string buffer. > > So I replace this: > > sb.append(" xxx: [" + getXXX() + "]\n"); > > for this: > > sb.append(" xxx: [").append(getXXX()).append("]\n"); > > The classes are: > > javax.imageio.plugins.jpeg.JPEGQTable > javax.management.openmbean.ArrayType > javax.naming.BinaryRefAddr > javax.naming.directory.BasicAttribute > javax.naming.NameImpl > javax.sound.sampled.AudioFileFormat > > > The diff bellow: > > > diff --git a/src/share/classes/javax/management/openmbean/ArrayType.java > b/src/share/classes/javax/management/openmbean/ArrayType.java > --- a/src/share/classes/javax/management/openmbean/ArrayType.java > +++ b/src/share/classes/javax/management/openmbean/ArrayType.java > @@ -459,7 +459,7 @@ > isPrimitiveArray = at.isPrimitiveArray(); > } > StringBuilder result = > - new StringBuilder(dimension + "-dimension array of "); > + new StringBuilder(dimension).append("-dimension array of "); > final String elementClassName = elementType.getClassName(); > if (isPrimitiveArray) { > // Convert from wrapper type to primitive type > > > > > diff --git a/src/share/classes/javax/sound/sampled/AudioFileFormat.java > b/src/share/classes/javax/sound/sampled/AudioFileFormat.java > --- a/src/share/classes/javax/sound/sampled/AudioFileFormat.java > +++ b/src/share/classes/javax/sound/sampled/AudioFileFormat.java > @@ -288,19 +288,20 @@ > > //$$fb2002-11-01: fix for 4672864: AudioFileFormat.toString() > throws unexpected NullPointerException > if (type != null) { > - buf.append(type.toString() + " (." + type.getExtension() + ") > file"); > + buf.append(type.toString()).append(" > (.").append(type.getExtension()).append(") file"); > + > } else { > buf.append("unknown file format"); > } > > if (byteLength != AudioSystem.NOT_SPECIFIED) { > - buf.append(", byte length: " + byteLength); > + buf.append(", byte length: ").append(byteLength); > } > > - buf.append(", data format: " + format); > + buf.append(", data format: ").append(format); > > if (frameLength != AudioSystem.NOT_SPECIFIED) { > - buf.append(", frame length: " + frameLength); > + buf.append(", frame length: ").append(frameLength); > } > > return new String(buf); > > > > > diff --git a/src/share/classes/javax/naming/directory/BasicAttribute.java > b/src/share/classes/javax/naming/directory/BasicAttribute.java > --- a/src/share/classes/javax/naming/directory/BasicAttribute.java > +++ b/src/share/classes/javax/naming/directory/BasicAttribute.java > @@ -211,7 +211,7 @@ > * @return The non-null string representation of this attribute. > */ > public String toString() { > - StringBuffer answer = new StringBuffer(attrID + ": "); > + StringBuffer answer = new StringBuffer(attrID).append(": "); > if (values.size() == 0) { > answer.append("No values"); > } else { > > > > > diff --git a/src/share/classes/javax/naming/BinaryRefAddr.java > b/src/share/classes/javax/naming/BinaryRefAddr.java > --- a/src/share/classes/javax/naming/BinaryRefAddr.java > +++ b/src/share/classes/javax/naming/BinaryRefAddr.java > @@ -169,7 +169,7 @@ > > str.append("AddressContents: "); > for (int i = 0; i - str.append(Integer.toHexString(buf[i]) +" "); > + str.append(Integer.toHexString(buf[i])).append(" "); > } > if (buf.length >= 32) > str.append(" ...\n"); > > > > > diff --git a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java > b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java > --- a/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java > +++ b/src/share/classes/javax/imageio/plugins/jpeg/JPEGQTable.java > @@ -197,7 +197,7 @@ > */ > public String toString() { > String ls = System.getProperty("line.separator", "\n"); > - StringBuilder sb = new StringBuilder("JPEGQTable:"+ls); > + StringBuilder sb = new StringBuilder("JPEGQTable:").append(ls); > for (int i=0; i < qTable.length; i++) { > if (i % 8 == 0) { > sb.append('\t'); > > > > > diff --git a/src/share/classes/javax/naming/NameImpl.java > b/src/share/classes/javax/naming/NameImpl.java > --- a/src/share/classes/javax/naming/NameImpl.java > +++ b/src/share/classes/javax/naming/NameImpl.java > @@ -170,7 +170,7 @@ > endQuote = one ? syntaxEndQuote1 : syntaxEndQuote2; > > i += syntaxTypevalSeparator.length(); > - answer.append(syntaxTypevalSeparator+beginQuote); // add > back > + answer.append(syntaxTypevalSeparator).append(beginQuote); > // add back > > // consume string until matching quote > for (i += beginQuote.length(); > > > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From mike.duigou at oracle.com Fri Jun 7 22:22:26 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 7 Jun 2013 15:22:26 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: Thank you for the review Martin. On Jun 7 2013, at 14:51 , Martin Buchholz wrote: > is denigrated in favor of {@code ? Yes. {@code} is preferred because it treats the content as literals. This means you can use it to wrap text (usually generics) that have to represented using html entities (& < >) or would be interpreted as html tags. List<A extends Awesome & Comparable<? super Awesome>> vs {@code List>}. The {@code} form is less error prone. I would love to do this replacement globally along with -> and -> > --- > > "specified navigable set" ? > > + * The returned navigable set will be serializable if the specified sorted set > + * is serializable. Corrected. > --- > > Y U NO throw UOE? > > + @Override > + public Entry pollFirstEntry() { > + Entry entry = (Entry) nm.pollFirstEntry(); > + return (null == entry) ? null : new UnmodifiableEntrySet.UnmodifiableEntry(entry); > + } Ouch! I will fix this and see what additional test improvements this suggests. > > --- > navigable set? > > + * Returns a synchronized (thread-safe) sorted set backed by the specified > + * navigable set. In order to guarantee serial access, it is critical that Corrected. > > On Fri, Jun 7, 2013 at 10:58 AM, Mike Duigou wrote: > Hello all; > > I've incorporated feedback from previous rounds and expect to finalize this addition soon. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ > > Any review feedback or suggestions of additional tests welcome. > > Thanks, > > Mike > > > From otaviojava at java.net Fri Jun 7 22:27:50 2013 From: otaviojava at java.net (=?ISO-8859-1?Q?Ot=E1vio_Gon=E7alves_de_Santana?=) Date: Fri, 7 Jun 2013 19:27:50 -0300 Subject: Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] {Package: sun.*} In-Reply-To: References: Message-ID: I did one more refactoring in this packages. diff --git a/src/share/classes/sun/management/Agent.java b/src/share/classes/sun/management/Agent.java --- a/src/share/classes/sun/management/Agent.java +++ b/src/share/classes/sun/management/Agent.java @@ -497,7 +497,7 @@ } else { StringBuffer message = new StringBuffer(params[0]); for (int i = 1; i < params.length; i++) { - message.append(" " + params[i]); + message.append(' ').append(params[i]); } error(key, message.toString()); } diff --git a/src/share/classes/sun/reflect/annotation/AnnotationType.java b/src/share/classes/sun/reflect/annotation/AnnotationType.java --- a/src/share/classes/sun/reflect/annotation/AnnotationType.java +++ b/src/share/classes/sun/reflect/annotation/AnnotationType.java @@ -205,11 +205,11 @@ * For debugging. */ public String toString() { - StringBuffer s = new StringBuffer("Annotation Type:" + "\n"); - s.append(" Member types: " + memberTypes + "\n"); - s.append(" Member defaults: " + memberDefaults + "\n"); - s.append(" Retention policy: " + retention + "\n"); - s.append(" Inherited: " + inherited); + StringBuffer s = new StringBuffer("Annotation Type:").append('\n'); + s.append(" Member types: " ).append( memberTypes ).append( '\n'); + s.append(" Member defaults: " ).append( memberDefaults ).append( '\n'); + s.append(" Retention policy: " ).append( retention ).append( '\n'); + s.append(" Inherited: " ).append( inherited); return s.toString(); } } diff --git a/src/share/classes/sun/font/Decoration.java b/src/share/classes/sun/font/Decoration.java --- a/src/share/classes/sun/font/Decoration.java +++ b/src/share/classes/sun/font/Decoration.java @@ -430,12 +430,12 @@ StringBuffer buf = new StringBuffer(); buf.append(super.toString()); buf.append("["); - if (fgPaint != null) buf.append("fgPaint: " + fgPaint); - if (bgPaint != null) buf.append(" bgPaint: " + bgPaint); + if (fgPaint != null) buf.append("fgPaint: ").append(fgPaint); + if (bgPaint != null) buf.append(" bgPaint: ").append(bgPaint); if (swapColors) buf.append(" swapColors: true"); if (strikethrough) buf.append(" strikethrough: true"); - if (stdUnderline != null) buf.append(" stdUnderline: " + stdUnderline); - if (imUnderline != null) buf.append(" imUnderline: " + imUnderline); + if (stdUnderline != null) buf.append(" stdUnderline: ").append(stdUnderline); + if (imUnderline != null) buf.append(" imUnderline: ").append(imUnderline); buf.append("]"); return buf.toString(); } diff --git a/src/share/classes/sun/net/www/MimeEntry.java b/src/share/classes/sun/net/www/MimeEntry.java --- a/src/share/classes/sun/net/www/MimeEntry.java +++ b/src/share/classes/sun/net/www/MimeEntry.java @@ -297,7 +297,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("application=" + command); + buf.append("application=").append(command); needSeparator = true; } @@ -305,7 +305,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("icon=" + getImageFileName()); + buf.append("icon=").append(getImageFileName()); needSeparator = true; } @@ -314,7 +314,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("file_extensions=" + extensions); + buf.append("file_extensions=").append(extensions); needSeparator = true; } @@ -323,7 +323,7 @@ if (needSeparator) { buf.append(separator); } - buf.append("description=" + description); + buf.append("description=" ).append(description); } return buf.toString(); diff --git a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java --- a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java +++ b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java @@ -68,7 +68,7 @@ sb.append("local://").append(lvmid).append("@localhost"); if (mode != null) { - sb.append("?mode=" + mode); + sb.append("?mode=").append(mode); } String vmidStr = sb.toString(); diff --git a/src/share/classes/sun/font/StandardGlyphVector.java b/src/share/classes/sun/font/StandardGlyphVector.java --- a/src/share/classes/sun/font/StandardGlyphVector.java +++ b/src/share/classes/sun/font/StandardGlyphVector.java @@ -1894,7 +1894,7 @@ } } catch(Exception e) { - buf.append(" " + e.getMessage()); + buf.append(' ').append(e.getMessage()); } buf.append("}"); diff --git a/src/share/classes/sun/awt/datatransfer/SunClipboard.java b/src/share/classes/sun/awt/datatransfer/SunClipboard.java --- a/src/share/classes/sun/awt/datatransfer/SunClipboard.java +++ b/src/share/classes/sun/awt/datatransfer/SunClipboard.java @@ -87,7 +87,7 @@ public SunClipboard(String name) { super(name); - CLIPBOARD_FLAVOR_LISTENER_KEY = new StringBuffer(name + "_CLIPBOARD_FLAVOR_LISTENER_KEY"); + CLIPBOARD_FLAVOR_LISTENER_KEY = new StringBuffer(name).append("_CLIPBOARD_FLAVOR_LISTENER_KEY"); } public synchronized void setContents(Transferable contents, diff --git a/src/share/classes/sun/security/acl/AclEntryImpl.java b/src/share/classes/sun/security/acl/AclEntryImpl.java --- a/src/share/classes/sun/security/acl/AclEntryImpl.java +++ b/src/share/classes/sun/security/acl/AclEntryImpl.java @@ -147,7 +147,7 @@ s.append("Group."); else s.append("User."); - s.append(user + "="); + s.append(user).append('='); Enumeration e = permissions(); while(e.hasMoreElements()) { Permission p = e.nextElement(); diff --git a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java --- a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java +++ b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java @@ -640,7 +640,7 @@ for (int i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { - digestString.append("0" + + digestString.append('0').append( Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( diff --git a/src/share/classes/sun/security/ssl/HandshakeMessage.java b/src/share/classes/sun/security/ssl/HandshakeMessage.java --- a/src/share/classes/sun/security/ssl/HandshakeMessage.java +++ b/src/share/classes/sun/security/ssl/HandshakeMessage.java @@ -1478,7 +1478,7 @@ boolean opened = false; for (SignatureAndHashAlgorithm signAlg : algorithms) { if (opened) { - buffer.append(", " + signAlg.getAlgorithmName()); + buffer.append(", ").append(signAlg.getAlgorithmName()); } else { buffer.append(signAlg.getAlgorithmName()); opened = true; diff --git a/src/share/classes/sun/security/krb5/KrbException.java b/src/share/classes/sun/security/krb5/KrbException.java --- a/src/share/classes/sun/security/krb5/KrbException.java +++ b/src/share/classes/sun/security/krb5/KrbException.java @@ -96,7 +96,7 @@ public String krbErrorMessage() { - StringBuffer strbuf = new StringBuffer("krb_error " + returnCode); + StringBuffer strbuf = new StringBuffer("krb_error ").append(returnCode); String msg = getMessage(); if (msg != null) { strbuf.append(" "); diff --git a/src/share/classes/sun/security/x509/PolicyInformation.java b/src/share/classes/sun/security/x509/PolicyInformation.java --- a/src/share/classes/sun/security/x509/PolicyInformation.java +++ b/src/share/classes/sun/security/x509/PolicyInformation.java @@ -258,8 +258,8 @@ * Return a printable representation of the PolicyInformation. */ public String toString() { - StringBuilder s = new StringBuilder(" [" + policyIdentifier.toString()); - s.append(policyQualifiers + " ]\n"); + StringBuilder s = new StringBuilder(" [").append( policyIdentifier.toString()); + s.append(policyQualifiers).append(" ]\n"); return s.toString(); } diff --git a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java --- a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java +++ b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java @@ -158,8 +158,8 @@ } buffer.append(hexDumper.encode(certHash)); if (issuer != null && serialNumber != null) { - buffer.append("\n\tIssuer: " + issuer + "\n"); - buffer.append("\t" + serialNumber); + buffer.append("\n\tIssuer: " ).append( issuer ).append( '\n'); + buffer.append('\t').append( serialNumber); } buffer.append("\n]"); return buffer.toString(); On Fri, Jun 7, 2013 at 10:22 AM, Ot?vio Gon?alves de Santana < otaviojava at java.net> wrote: > Inefficient use StringBuffer or StringBuilder[Optimization|clean-up] > > The string addition in the parameter will create another string buffer, > append all the components, then convert that to a string so the you can be > appended to your string buffer. > > So I replace this: > > sb.append(" xxx: [" + getXXX() + "]\n"); > > for this: > > sb.append(" xxx: [").append(getXXX()).append("]\n"); > > The classes are: > > > -- sun > sun.awt.datatransfer.SunClipboard > sun.font.Decoration > sun.font.StandardGlyphVector > sun.management.Agent > sun.net.www.MimeEntry > sun.reflect.annotation.AnnotationType > sun.tools.jstatd.RemoteHostImpl > > > sun.security.acl.AclEntryImpl > sun.security.krb5.internal.crypto.dk.DkCrypto > sun.security.krb5.KrbException > sun.security.pkcs.SigningCertificateInfo > sun.security.ssl.HandshakeMessage > sun.security.x509.PolicyInformation > sun.security.x509.X509CRLImpl > > > The diff bellow: > > > diff --git a/src/share/classes/sun/management/Agent.java > b/src/share/classes/sun/management/Agent.java > --- a/src/share/classes/sun/management/Agent.java > +++ b/src/share/classes/sun/management/Agent.java > @@ -497,7 +497,7 @@ > } else { > StringBuffer message = new StringBuffer(params[0]); > for (int i = 1; i < params.length; i++) { > - message.append(" " + params[i]); > + message.append(" ").append(params[i]); > } > error(key, message.toString()); > } > > > > > diff --git a/src/share/classes/sun/reflect/annotation/AnnotationType.java > b/src/share/classes/sun/reflect/annotation/AnnotationType.java > --- a/src/share/classes/sun/reflect/annotation/AnnotationType.java > +++ b/src/share/classes/sun/reflect/annotation/AnnotationType.java > @@ -205,11 +205,11 @@ > * For debugging. > */ > public String toString() { > - StringBuffer s = new StringBuffer("Annotation Type:" + "\n"); > - s.append(" Member types: " + memberTypes + "\n"); > - s.append(" Member defaults: " + memberDefaults + "\n"); > - s.append(" Retention policy: " + retention + "\n"); > - s.append(" Inherited: " + inherited); > + StringBuffer s = new StringBuffer("Annotation > Type:").append("\n"); > + s.append(" Member types: " ).append( memberTypes ).append( > "\n"); > + s.append(" Member defaults: " ).append( memberDefaults > ).append( "\n"); > + s.append(" Retention policy: " ).append( retention ).append( > "\n"); > + s.append(" Inherited: " ).append( inherited); > return s.toString(); > } > } > > > > > diff --git a/src/share/classes/sun/font/Decoration.java > b/src/share/classes/sun/font/Decoration.java > --- a/src/share/classes/sun/font/Decoration.java > +++ b/src/share/classes/sun/font/Decoration.java > @@ -430,12 +430,12 @@ > StringBuffer buf = new StringBuffer(); > buf.append(super.toString()); > buf.append("["); > - if (fgPaint != null) buf.append("fgPaint: " + fgPaint); > - if (bgPaint != null) buf.append(" bgPaint: " + bgPaint); > + if (fgPaint != null) buf.append("fgPaint: ").append(fgPaint); > + if (bgPaint != null) buf.append(" bgPaint: ").append(bgPaint); > if (swapColors) buf.append(" swapColors: true"); > if (strikethrough) buf.append(" strikethrough: true"); > - if (stdUnderline != null) buf.append(" stdUnderline: " + > stdUnderline); > - if (imUnderline != null) buf.append(" imUnderline: " + > imUnderline); > + if (stdUnderline != null) buf.append(" stdUnderline: > ").append(stdUnderline); > + if (imUnderline != null) buf.append(" imUnderline: > ").append(imUnderline); > buf.append("]"); > return buf.toString(); > } > > > > > diff --git a/src/share/classes/sun/net/www/MimeEntry.java > b/src/share/classes/sun/net/www/MimeEntry.java > --- a/src/share/classes/sun/net/www/MimeEntry.java > +++ b/src/share/classes/sun/net/www/MimeEntry.java > @@ -297,7 +297,7 @@ > if (needSeparator) { > buf.append(separator); > } > - buf.append("application=" + command); > + buf.append("application=").append(command); > needSeparator = true; > } > > @@ -305,7 +305,7 @@ > if (needSeparator) { > buf.append(separator); > } > - buf.append("icon=" + getImageFileName()); > + buf.append("icon=").append(getImageFileName()); > needSeparator = true; > } > > @@ -314,7 +314,7 @@ > if (needSeparator) { > buf.append(separator); > } > - buf.append("file_extensions=" + extensions); > + buf.append("file_extensions=").append(extensions); > needSeparator = true; > } > > @@ -323,7 +323,7 @@ > if (needSeparator) { > buf.append(separator); > } > - buf.append("description=" + description); > + buf.append("description=" ).append(description); > } > > return buf.toString(); > > > > > diff --git a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java > b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java > --- a/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java > +++ b/src/share/classes/sun/tools/jstatd/RemoteHostImpl.java > @@ -68,7 +68,7 @@ > > sb.append("local://").append(lvmid).append("@localhost"); > if (mode != null) { > - sb.append("?mode=" + mode); > + sb.append("?mode=").append(mode); > } > > String vmidStr = sb.toString(); > > > > > diff --git a/src/share/classes/sun/font/StandardGlyphVector.java > b/src/share/classes/sun/font/StandardGlyphVector.java > --- a/src/share/classes/sun/font/StandardGlyphVector.java > +++ b/src/share/classes/sun/font/StandardGlyphVector.java > @@ -1894,7 +1894,7 @@ > } > } > catch(Exception e) { > - buf.append(" " + e.getMessage()); > + buf.append(" ").append(e.getMessage()); > } > buf.append("}"); > > > > > > diff --git a/src/share/classes/sun/awt/datatransfer/SunClipboard.java > b/src/share/classes/sun/awt/datatransfer/SunClipboard.java > --- a/src/share/classes/sun/awt/datatransfer/SunClipboard.java > +++ b/src/share/classes/sun/awt/datatransfer/SunClipboard.java > @@ -87,7 +87,7 @@ > > public SunClipboard(String name) { > super(name); > - CLIPBOARD_FLAVOR_LISTENER_KEY = new StringBuffer(name + > "_CLIPBOARD_FLAVOR_LISTENER_KEY"); > + CLIPBOARD_FLAVOR_LISTENER_KEY = new > StringBuffer(name).append("_CLIPBOARD_FLAVOR_LISTENER_KEY"); > } > > public synchronized void setContents(Transferable contents, > > > > > > > > diff --git a/src/share/classes/sun/security/acl/AclEntryImpl.java > b/src/share/classes/sun/security/acl/AclEntryImpl.java > --- a/src/share/classes/sun/security/acl/AclEntryImpl.java > +++ b/src/share/classes/sun/security/acl/AclEntryImpl.java > @@ -147,7 +147,7 @@ > s.append("Group."); > else > s.append("User."); > - s.append(user + "="); > + s.append(user).append("="); > Enumeration e = permissions(); > while(e.hasMoreElements()) { > Permission p = e.nextElement(); > > > > > diff --git > a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java > b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java > --- a/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java > +++ b/src/share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java > @@ -640,7 +640,7 @@ > > for (int i = 0; i < digest.length; i++) { > if ((digest[i] & 0x000000ff) < 0x10) { > - digestString.append("0" + > + digestString.append("0").append( > Integer.toHexString(digest[i] & 0x000000ff)); > } else { > digestString.append( > > > > > diff --git a/src/share/classes/sun/security/ssl/HandshakeMessage.java > b/src/share/classes/sun/security/ssl/HandshakeMessage.java > --- a/src/share/classes/sun/security/ssl/HandshakeMessage.java > +++ b/src/share/classes/sun/security/ssl/HandshakeMessage.java > @@ -1478,7 +1478,7 @@ > boolean opened = false; > for (SignatureAndHashAlgorithm signAlg : algorithms) { > if (opened) { > - buffer.append(", " + signAlg.getAlgorithmName()); > + buffer.append(", > ").append(signAlg.getAlgorithmName()); > } else { > buffer.append(signAlg.getAlgorithmName()); > opened = true; > > > > > diff --git a/src/share/classes/sun/security/krb5/KrbException.java > b/src/share/classes/sun/security/krb5/KrbException.java > --- a/src/share/classes/sun/security/krb5/KrbException.java > +++ b/src/share/classes/sun/security/krb5/KrbException.java > @@ -96,7 +96,7 @@ > > > public String krbErrorMessage() { > - StringBuffer strbuf = new StringBuffer("krb_error " + returnCode); > + StringBuffer strbuf = new StringBuffer("krb_error > ").append(returnCode); > String msg = getMessage(); > if (msg != null) { > strbuf.append(" "); > > > > > diff --git a/src/share/classes/sun/security/x509/PolicyInformation.java > b/src/share/classes/sun/security/x509/PolicyInformation.java > --- a/src/share/classes/sun/security/x509/PolicyInformation.java > +++ b/src/share/classes/sun/security/x509/PolicyInformation.java > @@ -258,8 +258,8 @@ > * Return a printable representation of the PolicyInformation. > */ > public String toString() { > - StringBuilder s = new StringBuilder(" [" + > policyIdentifier.toString()); > - s.append(policyQualifiers + " ]\n"); > + StringBuilder s = new StringBuilder(" [").append( > policyIdentifier.toString()); > + s.append(policyQualifiers).append(" ]\n"); > return s.toString(); > } > > > > > > diff --git > a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java > b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java > --- a/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java > +++ b/src/share/classes/sun/security/pkcs/SigningCertificateInfo.java > @@ -158,8 +158,8 @@ > } > buffer.append(hexDumper.encode(certHash)); > if (issuer != null && serialNumber != null) { > - buffer.append("\n\tIssuer: " + issuer + "\n"); > - buffer.append("\t" + serialNumber); > + buffer.append("\n\tIssuer: " ).append( issuer ).append( "\n"); > + buffer.append("\t").append( serialNumber); > } > buffer.append("\n]"); > return buffer.toString(); > > > > > > > > -- > Atenciosamente. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: http://www.otaviojava.com.br > (11) 98255-3513 > > -- Atenciosamente. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513 From john.r.rose at oracle.com Fri Jun 7 22:44:11 2013 From: john.r.rose at oracle.com (John Rose) Date: Fri, 7 Jun 2013 15:44:11 -0700 Subject: Is there a better way to throw this exception? In-Reply-To: <51B0599D.4020906@oracle.com> References: <51B0599D.4020906@oracle.com> Message-ID: Puzzles! Probably you can use the new syntax "catch (Ex1|Ex2 ex)" to bind the first exception to a union type. You'll have to split the loop, but you could use a common iterator. for (Iterator it = all changes; it.hasNext(); ) { try { it.next(); once(); return; } catch (One|Two ex) { while (it.hasNext()) { try { it.next(); once(); return; } catch (One|Two ex) { /*ignore all but 1st*/ } } throw ex; /*throw 1st*/ } } On Jun 6, 2013, at 2:42 AM, Weijun Wang wrote: > Hi All > > I have a method that could throw two kinds of checked exceptions and possibly other unchecked ones: > > void once() throws One, Two > > Now I have a wrapper method that calls once() for multiple times, and want to throw the first exception if *all* fails. Now it looks like > > void multiple() throws One, Two { > Exception saved = null; > for (all chances) { > try { > once(); > return; > } catch (Exception e) { > if (saved != null) saved = e; > } > } > if (saved instanceof One) { > throw (One)saved; > } else if (saved instanceof One) { > throw (Two)saved; > } else if (saved instanceof RuntimeException) { > throw (RuntimeException)saved; > } else { > // Not likely, but I've already wrote so many lines. > throw new RuntimeException(saved); > } > } > > Is there any way I can make it shorter? > > Thanks > Max From jonathan.gibbons at oracle.com Fri Jun 7 22:36:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 07 Jun 2013 22:36:26 +0000 Subject: hg: jdk8/tl/langtools: 8016193: Fix OAC issue in langtools docs Message-ID: <20130607223632.33AE9480B4@hg.openjdk.java.net> Changeset: fd31bf97340f Author: jjg Date: 2013-06-07 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fd31bf97340f 8016193: Fix OAC issue in langtools docs Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/Tag.java From kumar.x.srinivasan at oracle.com Sat Jun 8 00:52:03 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 07 Jun 2013 17:52:03 -0700 Subject: RFR: JDK-8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing (XS) Message-ID: <51B28033.5090306@oracle.com> Hi, Can I get a quick review please, the fix excludes j2sdk-image/bin/jmc{.exe} from the test, which invokes the tool and verifies that -version and -Joptions work. As the subject says invoking this tool with any option puts up a window, hanging up the test. Thanks Kumar diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java +++ b/test/tools/launcher/VersionCheck.java @@ -49,6 +49,7 @@ "javaw", "javaws", "jcontrol", + "jmc", "jvisualvm", "packager", "unpack200", @@ -72,6 +73,7 @@ "jdeps", "jinfo", "jmap", + "jmc", "jps", "jrunscript", "jjs", From mike.duigou at oracle.com Sat Jun 8 01:20:16 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 7 Jun 2013 18:20:16 -0700 Subject: RFR: 8016213 : (S) Convert j2se NetBeans project to new build infrastructure Message-ID: <11FB774F-E08B-401E-8D28-BB79C1149757@oracle.com> Hello all; I took a look today at converting the existing J2SE NetBeans project to use the new build infrastructure. It turned out to be easier than I thought! Below is the patch needed to invoke the top level make file 'clean-jdk' and 'jdk' targets. It requires that have previously run the configure step and that you only have a single configuration in your build directory (It doesn't know anything about CONF or SPEC yet). I have successfully built the jdk target using this change on MacOS X and Linux x64. Mike P.S.: This is the first of a series of changesets which will complete the conversion of the OpenJDK JDK NetBeans projects to the new build infrastructure. Follow http://bugs.sun.com/view_bug.do?bug_id=8016213 to track the progress. diff --git a/make/netbeans/common/shared.xml b/make/netbeans/common/shared.xml --- a/make/netbeans/common/shared.xml +++ b/make/netbeans/common/shared.xml @@ -77,7 +77,7 @@ System configuration claims architecture is ${platform}-${arch} - + diff --git a/make/netbeans/j2se/build.xml b/make/netbeans/j2se/build.xml --- a/make/netbeans/j2se/build.xml +++ b/make/netbeans/j2se/build.xml @@ -37,11 +37,11 @@ - + - + From joe.darcy at oracle.com Sat Jun 8 01:59:28 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 07 Jun 2013 18:59:28 -0700 Subject: RFR: JDK-8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing (XS) In-Reply-To: <51B28033.5090306@oracle.com> References: <51B28033.5090306@oracle.com> Message-ID: <51B29000.9000202@oracle.com> Approved. -Joe On 6/7/2013 5:52 PM, Kumar Srinivasan wrote: > Hi, > > Can I get a quick review please, the fix excludes > j2sdk-image/bin/jmc{.exe} > from the test, which invokes the tool and verifies that -version and > -Joptions work. > As the subject says invoking this tool with any option puts up a > window, hanging up > the test. > > Thanks > Kumar > > > diff --git a/test/tools/launcher/VersionCheck.java > b/test/tools/launcher/VersionCheck.java > --- a/test/tools/launcher/VersionCheck.java > +++ b/test/tools/launcher/VersionCheck.java > @@ -49,6 +49,7 @@ > "javaw", > "javaws", > "jcontrol", > + "jmc", > "jvisualvm", > "packager", > "unpack200", > @@ -72,6 +73,7 @@ > "jdeps", > "jinfo", > "jmap", > + "jmc", > "jps", > "jrunscript", > "jjs", > From coleen.phillimore at oracle.com Sat Jun 8 02:35:04 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 08 Jun 2013 02:35:04 +0000 Subject: hg: jdk8/tl/jdk: 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted Message-ID: <20130608023516.D578F480BD@hg.openjdk.java.net> Changeset: f18337edd201 Author: coleenp Date: 2013-06-07 22:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f18337edd201 7124706: enable RetransformBigClass.sh test when fix for 8013063 is promoted Summary: The code for this test is fixed now and integrated to TL repo and it passes now. Reviewed-by: alanb ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/RetransformBigClass.sh From chris.hegarty at oracle.com Sat Jun 8 07:07:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 8 Jun 2013 08:07:13 +0100 Subject: RFR: 8016213 : (S) Convert j2se NetBeans project to new build infrastructure In-Reply-To: <11FB774F-E08B-401E-8D28-BB79C1149757@oracle.com> References: <11FB774F-E08B-401E-8D28-BB79C1149757@oracle.com> Message-ID: <22036163-3E8F-4495-834D-2A6A16E1CF1B@oracle.com> Looks ok to Mike. -Chris On 8 Jun 2013, at 02:20, Mike Duigou wrote: > Hello all; > > I took a look today at converting the existing J2SE NetBeans project to use the new build infrastructure. It turned out to be easier than I thought! > > Below is the patch needed to invoke the top level make file 'clean-jdk' and 'jdk' targets. It requires that have previously run the configure step and that you only have a single configuration in your build directory (It doesn't know anything about CONF or SPEC yet). > > I have successfully built the jdk target using this change on MacOS X and Linux x64. > > Mike > > P.S.: This is the first of a series of changesets which will complete the conversion of the OpenJDK JDK NetBeans projects to the new build infrastructure. Follow http://bugs.sun.com/view_bug.do?bug_id=8016213 to track the progress. > > > > > diff --git a/make/netbeans/common/shared.xml b/make/netbeans/common/shared.xml > --- a/make/netbeans/common/shared.xml > +++ b/make/netbeans/common/shared.xml > @@ -77,7 +77,7 @@ > System configuration claims architecture is ${platform}-${arch} > > > - > + > > > > diff --git a/make/netbeans/j2se/build.xml b/make/netbeans/j2se/build.xml > --- a/make/netbeans/j2se/build.xml > +++ b/make/netbeans/j2se/build.xml > @@ -37,11 +37,11 @@ > > > > - > + > > > > - > + > > > > From chris.hegarty at oracle.com Sat Jun 8 07:11:44 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 8 Jun 2013 08:11:44 +0100 Subject: RFR: JDK-8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing (XS) In-Reply-To: <51B29000.9000202@oracle.com> References: <51B28033.5090306@oracle.com> <51B29000.9000202@oracle.com> Message-ID: On 8 Jun 2013, at 02:59, Joe Darcy wrote: > Approved. +1 -Chris. > > -Joe > > On 6/7/2013 5:52 PM, Kumar Srinivasan wrote: >> Hi, >> >> Can I get a quick review please, the fix excludes j2sdk-image/bin/jmc{.exe} >> from the test, which invokes the tool and verifies that -version and -Joptions work. >> As the subject says invoking this tool with any option puts up a window, hanging up >> the test. >> >> Thanks >> Kumar >> >> >> diff --git a/test/tools/launcher/VersionCheck.java b/test/tools/launcher/VersionCheck.java >> --- a/test/tools/launcher/VersionCheck.java >> +++ b/test/tools/launcher/VersionCheck.java >> @@ -49,6 +49,7 @@ >> "javaw", >> "javaws", >> "jcontrol", >> + "jmc", >> "jvisualvm", >> "packager", >> "unpack200", >> @@ -72,6 +73,7 @@ >> "jdeps", >> "jinfo", >> "jmap", >> + "jmc", >> "jps", >> "jrunscript", >> "jjs", > From Alan.Bateman at oracle.com Sat Jun 8 07:12:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 08 Jun 2013 08:12:11 +0100 Subject: RFR: JDK-8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing (XS) In-Reply-To: <51B28033.5090306@oracle.com> References: <51B28033.5090306@oracle.com> Message-ID: <51B2D94B.4020301@oracle.com> On 08/06/2013 01:52, Kumar Srinivasan wrote: > Hi, > > Can I get a quick review please, the fix excludes > j2sdk-image/bin/jmc{.exe} > from the test, which invokes the tool and verifies that -version and > -Joptions work. > As the subject says invoking this tool with any option puts up a > window, hanging up > the test. Looks good to me. -Alan From forax at univ-mlv.fr Sat Jun 8 10:21:14 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 08 Jun 2013 12:21:14 +0200 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B1AF6C.5030708@oracle.com> References: <51B1AF6C.5030708@oracle.com> Message-ID: <51B3059A.4030703@univ-mlv.fr> On 06/07/2013 12:01 PM, Aleksey Shipilev wrote: > (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as Christian T. > suggested offline) > > Hi guys, Hi Aleksey, > > The fix for scalability problem is here: > http://cr.openjdk.java.net/~shade/7177472/webrev.00/ in add, the do/while does something a little weird, if putIfAbsent returns null, interned is equals to elem, there is no need to do a e.get() in that case, I would prefer a code like this: T interned; do { expungeStaleElements(); WeakEntry e = new WeakEntry<>(elem, stale); WeakEntry exist = map.putIfAbsent(e, e); interned = (exist == null)? elem: exist.get(); } while (interned == null); return interned; The cast to WeakEntry in expungeStaleElements is not needed. In WeakEntry.equals, the null check is not needed because null instanceof WeakEntry returns false, and you don't need to cast obj.get() to a WeakEntry given you only to call equals on entry.get(). So the code should be: public boolean equals(Object obj) { if (!(obj instanceof WeakEntry)) { return false; } Object that = ((WeakEntry)obj).get(); Object mine = get(); return (that == null || mine == null)? this == obj: mine.equals(that); } Otherwise, it looks good. R?mi > > Testing: > - Linux x86_64 builds OK > - Linux x86_64 java/lang/invoke/ jtreg passes OK > > Since this is a proof-of-concept patch at this point, I kept the testing > minimal. Let me know what other testing you think is needed before the > integration. > > Thanks, > Aleksey. > > *** Rationale and details for the issue follow: *** > > This issue was in limbo for an year. The performance issue with > MethodType.methodType factory leads to abysmal scalability on the > targeted tests. While this can arguably demonstrated on larger > workloads, the targeted microbenchmarks are showcasing it nicely. This > issue was blocking the JSR292 API performance testing, because on large > enough test server, you will inevitably be bitten by this. > > If you run the JMH-enabled [1] microbenchmark: > http://openjdk.java.net/projects/code-tools/jmh/ > http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz > > ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will see > the scalability is going down. ("testCached" makes sure the reference to > MethodType is always strongly reachable, "testNew" makes sure the > reference is mostly non-reachable, prompting cache re-fill, "testOOB" > does not make any precautions about that, and also does not suffer from > the static overheads entailed by the reference management in first two > tests). > > 1 thread: > MethodTypeBench.testCached 78 +- 1 nsec/op > MethodTypeBench.testNew 120 +- 1 nsec/op > MethodTypeBench.testOOB 41 +- 1 nsec/op > > 4 threads: > MethodTypeBench.testCached 495 +- 40 nsec/op > MethodTypeBench.testNew 611 +- 37 nsec/op > MethodTypeBench.testOOB 377 +- 10 nsec/op > > In fact, on larger machines it may be as bad as tens/hundreds of > microseconds to look up the MethodType. With the patch applied, on the > same 2x2 machine: > > 1 thread: > MethodTypeBench.testCached 92 +- 1 nsec/op > MethodTypeBench.testNew 101 +- 1 nsec/op > MethodTypeBench.testOOB 49 +- 1 nsec/op > > 4 threads: > MethodTypeBench.testCached 129 +- 1 nsec/op > MethodTypeBench.testNew 142 +- 10 nsec/op > MethodTypeBench.testOOB 89 +- 3 nsec/op > > > ...which means the scalability is back: the average time to look up the > MethodType is not growing spectacularly when the thread count go up. > Again, the effect is astonishing on large machines. > > Notice that we took some hit in single-threaded performance, and that is > due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the > upcoming CHMv8, this starts to look better: > > 1 thread: > MethodTypeBench.testCached 87 +- 1 nsec/op > MethodTypeBench.testNew 95 +- 1 nsec/op > MethodTypeBench.testOOB 52 +- 1 nsec/op > > 4 threads: > MethodTypeBench.testCached 121 +- 2 nsec/op > MethodTypeBench.testNew 141 +- 1 nsec/op > MethodTypeBench.testOOB 93 +- 5 nsec/op > > ...which seems to indicate this change is future-proof. From aleksey.shipilev at oracle.com Sat Jun 8 11:21:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 08 Jun 2013 15:21:28 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B3059A.4030703@univ-mlv.fr> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> Message-ID: <51B313B8.1060309@oracle.com> (copying hotspot-dev@ back, the patch is theirs) Thanks Remi! On 06/08/2013 02:21 PM, Remi Forax wrote: > in add, the do/while does something a little weird, if putIfAbsent > returns null, interned is equals to elem, there is no need to do a > e.get() in that case, Oh yes, that a nice micro-optimization, relying on the fact $elem is still strongly reachable. > The cast to WeakEntry in expungeStaleElements is not needed. Yup. > In WeakEntry.equals, the null check is not needed because null > instanceof WeakEntry returns false, and you don't need to cast > obj.get() to a WeakEntry given you only to call equals on > entry.get(). Yup, thanks for the nit-picking this. > Otherwise, it looks good. I had also renamed the class to ConcurrentWeakInternSet, to emphasize it should do interning, not only the caching. The new webrev is here: http://cr.openjdk.java.net/~shade/7177472/webrev.01/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK - The microbenchmark scores in the original note are still in effect. -Aleksey. From dl at cs.oswego.edu Sat Jun 8 15:07:00 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 08 Jun 2013 11:07:00 -0400 Subject: Class.getGenericInterfaces performance improvement Message-ID: <51B34894.7030809@cs.oswego.edu> While tracking down performance issues in some reflective checks used inside ConcurrentHashMap, I noticed that method Class.getGenericInterfaces (as well as methods getGenericSuperclass and getTypeParameters) entail an expensive unnecessary recheck on each invocation. Each relies primarily on (internal) method getGenericInfo, that uses an instance cached on first invocation (or remains null if the class is not generic). But these calling methods preface the call with a call to getGenericSignature which is a relatively expensive JNI method. This call is unnecessary if the genericInfo has already been constructed. Reworking to avoid this makes repeated calls very noticeably faster. The diffs below show one way to do this. Could someone who works on reflection check and sponsor this change? Thanks! diff -r 30101f69e66f src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Fri May 17 10:11:35 2013 -0700 +++ b/src/share/classes/java/lang/Class.java Sat Jun 08 10:33:32 2013 -0400 @@ -707,8 +707,9 @@ */ @SuppressWarnings("unchecked") public TypeVariable>[] getTypeParameters() { - if (getGenericSignature() != null) - return (TypeVariable>[])getGenericInfo().getTypeParameters(); + ClassRepository info = getGenericInfo(); + if (info != null) + return (TypeVariable>[])info.getTypeParameters(); else return (TypeVariable>[])new TypeVariable[0]; } @@ -758,15 +759,13 @@ * @since 1.5 */ public Type getGenericSuperclass() { - if (getGenericSignature() != null) { - // Historical irregularity: - // Generic signature marks interfaces with superclass = Object - // but this API returns null for interfaces - if (isInterface()) - return null; - return getGenericInfo().getSuperclass(); - } else - return getSuperclass(); + // Historical irregularity: + // Generic signature marks interfaces with superclass = Object + // but this API returns null for interfaces + ClassRepository info = getGenericInfo(); + return (info == null ? getSuperclass() : + isInterface() ? null : + info.getSuperclass()); } /** @@ -881,10 +880,8 @@ * @since 1.5 */ public Type[] getGenericInterfaces() { - if (getGenericSignature() != null) - return getGenericInfo().getSuperInterfaces(); - else - return getInterfaces(); + ClassRepository info = getGenericInfo(); + return (info == null) ? getInterfaces() : info.getSuperInterfaces(); } @@ -2409,12 +2406,11 @@ // accessor for generic info repository private ClassRepository getGenericInfo() { // lazily initialize repository if necessary - if (genericInfo == null) { - // create and cache generic info repository - genericInfo = ClassRepository.make(getGenericSignature(), - getFactory()); - } - return genericInfo; //return cached repository + String signature; + ClassRepository info = genericInfo; + return (info != null ? info : + (signature = getGenericSignature()) == null ? null : + (genericInfo = ClassRepository.make(signature, getFactory()))); } // Annotations handling From dl at cs.oswego.edu Sat Jun 8 15:50:25 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 08 Jun 2013 11:50:25 -0400 Subject: Proposal: Comparables.isCommutativelyComparable Message-ID: <51B352C1.8050104@cs.oswego.edu> Suppose you have two objects, x and y, both of the same type (x.getClass() == y.getClass()) and both known to be instanceof Comparable. Can you compare them? That is, can you safely call (Comparable)x).compareTo(y); Almost always, the answer is yes, because almost all Comparable classes are of form "class C implements Comparable" But there's nothing about interface Comparable that forces this to be true. It would be weird but legal if both are of form, say, "class C implements Comparable". Which means that you cannot compare them to each other. There's currently no direct way to check if you have a normal commutative (bidirectionally applicable) pair of comparables. It can be checked using reflection though, using mechanics that are both messy and slower than they might be if implemented as a JDK utility method. There a few possible API choices for how to do this. The most basic is boolean isCommutativelyComparable(Class c); returning true if c represents a class form C implements Comparable. (It would be OK although a little annoying to use if it restricted argument type to Class>.) A more general one is: Class commutativelyComparableClassFor(Object x) that returns a class C such that (x instanceof C) and (C implements Comparable) or null if there is no such class. The return type could be strengthened to Class> This allows use of the result to match up objects of subclasses of commutatively comparable classes. The most handy form is: int compareIfCommutativelyComparable(Comparable x, Comparable y); that returns compareTo result if both of same commutatively comparable type, else 0. Maybe this one is *too* handy though. It's not hard to get the same effect manually given the above methods. Does anyone have any thoughts about introducing at least the first, and possibly the others into the java.util.Comparables utility class? If so, there would be a few immediate usages within JDK. I'm surprised that this hasn't come up for consideration before. Or maybe I haven't noticed previous discussions? -Doug From kumar.x.srinivasan at oracle.com Sat Jun 8 16:06:18 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 08 Jun 2013 16:06:18 +0000 Subject: hg: jdk8/tl/jdk: 8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing Message-ID: <20130608160659.8B001480C9@hg.openjdk.java.net> Changeset: c351a48c091d Author: ksrini Date: 2013-06-08 09:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c351a48c091d 8016209: TEST_BUG: non-compliant jmc in the bin directory hangs testing Reviewed-by: alanb, darcy, chegar ! test/tools/launcher/VersionCheck.java From maurizio.cimadamore at oracle.com Mon Jun 10 14:58:12 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 10 Jun 2013 14:58:12 +0000 Subject: hg: jdk8/tl/langtools: 8013576: Add stat support to LambdaToMethod Message-ID: <20130610145815.982C8480FA@hg.openjdk.java.net> Changeset: 3582b62dccb2 Author: mcimadamore Date: 2013-06-10 15:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3582b62dccb2 8013576: Add stat support to LambdaToMethod Summary: LambdaToMethod should emit info to help diagnose/test lambda metafactory problems Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/LambdaStat.java + test/tools/javac/diags/examples/MrefStat.java + test/tools/javac/diags/examples/MrefStat.java.rej + test/tools/javac/diags/examples/MrefStat1.java + test/tools/javac/diags/examples/MrefStat1.java.rej + test/tools/javac/lambda/TestLambdaToMethodStats.java From alan.bateman at oracle.com Mon Jun 10 12:26:11 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Jun 2013 12:26:11 +0000 Subject: hg: jdk8/tl/jdk: 8016217: More javadoc warnings Message-ID: <20130610122623.53380480ED@hg.openjdk.java.net> Changeset: d790064850a7 Author: alanb Date: 2013-06-10 12:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d790064850a7 8016217: More javadoc warnings Reviewed-by: lancea, chegar, psandoz ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/Console.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/io/StringReader.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookiePolicy.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/cert/CertPathValidatorException.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/X509Extension.java ! src/share/classes/java/security/spec/EllipticCurve.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/text/CharacterIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimerTask.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/regex/MatchResult.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/stream/package-info.java ! src/share/classes/java/util/zip/DeflaterInputStream.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/GZIPOutputStream.java ! src/share/classes/java/util/zip/InflaterInputStream.java ! src/share/classes/java/util/zip/InflaterOutputStream.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/javax/crypto/spec/IvParameterSpec.java ! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ! src/share/classes/javax/crypto/spec/SecretKeySpec.java ! src/share/classes/javax/naming/BinaryRefAddr.java ! src/share/classes/javax/naming/directory/Attribute.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/PagedResultsControl.java ! src/share/classes/javax/naming/ldap/SortControl.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLSessionContext.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/auth/callback/CallbackHandler.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslServer.java ! src/share/classes/javax/smartcardio/ResponseAPDU.java ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java From vicente.romero at oracle.com Mon Jun 10 14:19:39 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 10 Jun 2013 14:19:39 +0000 Subject: hg: jdk8/tl/langtools: 7113519: test/tools/javac/VersionOpt.java passes on windows Message-ID: <20130610141944.B8CB8480F6@hg.openjdk.java.net> Changeset: 105d1f9c1ab8 Author: vromero Date: 2013-06-10 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/105d1f9c1ab8 7113519: test/tools/javac/VersionOpt.java passes on windows Reviewed-by: jjg ! test/tools/javac/VersionOpt.java From paul.sandoz at oracle.com Mon Jun 10 10:31:22 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 10 Jun 2013 10:31:22 +0000 Subject: hg: jdk8/tl/jdk: 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator Message-ID: <20130610103136.25EBB480EA@hg.openjdk.java.net> Changeset: 9c462579b624 Author: psandoz Date: 2013-06-10 12:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c462579b624 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator Reviewed-by: chegar ! src/share/classes/java/util/Spliterators.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/TestData.java ! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java ! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java ! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java From paul.sandoz at oracle.com Mon Jun 10 10:22:50 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 10 Jun 2013 10:22:50 +0000 Subject: hg: jdk8/tl/jdk: 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream Message-ID: <20130610102302.5A304480E8@hg.openjdk.java.net> Changeset: 7322e8ad7c01 Author: psandoz Date: 2013-06-10 12:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7322e8ad7c01 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream Reviewed-by: alanb ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java From paul.sandoz at oracle.com Mon Jun 10 10:11:07 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 10 Jun 2013 10:11:07 +0000 Subject: hg: jdk8/tl/jdk: 8015492: Remove DoubleStream.range methods Message-ID: <20130610101129.A0F5E480E7@hg.openjdk.java.net> Changeset: 3990fcab2cd9 Author: psandoz Date: 2013-06-10 11:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3990fcab2cd9 8015492: Remove DoubleStream.range methods Reviewed-by: alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java From Alan.Bateman at oracle.com Mon Jun 10 15:05:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 16:05:11 +0100 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51B57185.3030607@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> <51A8E8D7.9030208@oracle.com> <51A9C76E.4090101@oracle.com> <51AAAB0B.1080202@oracle.com> <51AC6E98.9070907@oracle.com> <51B57185.3030607@oracle.com> Message-ID: <51B5EB27.9080605@oracle.com> On 10/06/2013 07:26, Dan Xu wrote: > > Hi Alan, > > Thank you for the clarification. I have updated the test and "if" > format at webrev, http://cr.openjdk.java.net/~dxu/8013827/webrev.02/. > Please review it. Thanks for changing it, it looks good now. -Alan From aleksey.shipilev at oracle.com Sat Jun 8 20:04:16 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sun, 9 Jun 2013 00:04:16 +0400 Subject: Proposal: Comparables.isCommutativelyComparable In-Reply-To: <52090F79-EA44-49A9-83FF-131F9CB9B103@oracle.com> References: <51B352C1.8050104@cs.oswego.edu> <52090F79-EA44-49A9-83FF-131F9CB9B103@oracle.com> Message-ID: <827C0B12-F609-4C60-89B8-B39840D36E10@oracle.com> On 08.06.2013, at 23:51, Aleksey Shipilev wrote: > Hm, sounds interesting. > > What's about yet another "factory"-like default in Comparator: > > Comparator Comparator.make(Class klass) > - returns synthetic comparator using C.compareTo iff C implements Comparable > - returns null otherwise Err... "make" actually suggests we better do the zero-return Comparator if there is no Comparable on the class. Which fits some of the things you want below. > > That will naively instantiate the Comparator, but there is the possibility to reuse e.g. ClassValue to lazily associate the default comparator with the class. > > -Aleksey. > > On 08.06.2013, at 19:50, Doug Lea
    wrote: > >> >> Suppose you have two objects, x and y, both of the same >> type (x.getClass() == y.getClass()) and both known >> to be instanceof Comparable. >> >> Can you compare them? That is, can you safely call >> (Comparable)x).compareTo(y); >> >> Almost always, the answer is yes, because almost all >> Comparable classes are of form "class C implements Comparable" >> >> But there's nothing about interface Comparable that forces >> this to be true. It would be weird but legal if both >> are of form, say, "class C implements Comparable". >> Which means that you cannot compare them to each other. >> >> There's currently no direct way to check if you have a normal >> commutative (bidirectionally applicable) pair of comparables. >> >> It can be checked using reflection though, using mechanics >> that are both messy and slower than they might be if >> implemented as a JDK utility method. >> >> There a few possible API choices for how to do this. >> >> The most basic is >> >> boolean isCommutativelyComparable(Class c); >> >> returning true if c represents a class form C implements Comparable. >> (It would be OK although a little annoying to use if it restricted >> argument type to Class>.) >> >> A more general one is: >> >> Class commutativelyComparableClassFor(Object x) >> >> that returns a class C such that >> (x instanceof C) and (C implements Comparable) >> or null if there is no such class. The return type could >> be strengthened to Class> >> >> This allows use of the result to match up objects of >> subclasses of commutatively comparable classes. >> >> The most handy form is: >> >> int compareIfCommutativelyComparable(Comparable x, Comparable y); >> >> that returns compareTo result if both of same commutatively >> comparable type, else 0. >> >> Maybe this one is *too* handy though. It's not hard to >> get the same effect manually given the above methods. >> >> Does anyone have any thoughts about introducing at >> least the first, and possibly the others into the >> java.util.Comparables utility class? If so, there would >> be a few immediate usages within JDK. >> >> I'm surprised that this hasn't come up for consideration >> before. Or maybe I haven't noticed previous discussions? >> >> -Doug >> >> >> From ivan.gerasimov at oracle.com Mon Jun 10 12:51:33 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 10 Jun 2013 16:51:33 +0400 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently Message-ID: <51B5CBD5.8040406@oracle.com> Hello everyone! The test of ThreadGroup.Suspend() was reported to fail on rare occasions. It can happen on a busy machine that 1 second delay would not be enough for the second thread to start. Then the first thread would suspend only itself and the test would fail. Earlier, another test was updated for similar reasons [1], [2]. The proposed test can still report false *positive* results if the second thread has had no chance to execute during one second after it had started. To avoid them there must be a way do distinguish suspended threads. WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 Sincerely yours, Ivan Gerasimov From aleksej.efimov at oracle.com Mon Jun 10 15:02:31 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 10 Jun 2013 19:02:31 +0400 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B4C82A.7070807@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> <51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com> <51B4C6F0.509@oracle.com> <51B4C82A.7070807@oracle.com> Message-ID: <51B5EA87.6090705@oracle.com> Hi Joe, We can replace the "Double.isNaN(d) || Double.isInfinite(d)" with "!Double.isFinite(d)" - I agree that this one check looks better, but we still need to do the -0.0 -> 0.0 conversion to solve the reported problem. And as I understand (might be wrong) modification of this check won't help us to achieve this goal, we still need to do the conversion: + //Convert -0.0 to +0.0 other values remains the same + d = d + 0.0; + Regards, -Aleksej On 06/09/2013 10:23 PM, Joe Darcy wrote: > Hello Aleksej, > > Looking at the code, I have another suggestion. If this code can run > exclusively on JDK 8 or later, replace > > 955 if (Double.isNaN(d) || Double.isInfinite(d)) > 956 return(Double.toString(d)); > > with > > 955 if (!Double.isFinite(d)) > 956 return(Double.toString(d)); > > Cheers, > > -Joe > > On 6/9/2013 11:18 AM, Aleksej Efimov wrote: >> Joe, >> >> I definitely like it: >> 1. Its a one-line change - perfect size. >> 2. Its fastest one from discussed previously. >> 3. -0.0 -> 0.0 has tests. >> 4. And it solves our problem. >> >> As a result of all props the next version of webrev: >> http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ >> >> >> Thanks >> -Aleksej >> >> On 06/07/2013 11:11 PM, huizhe wang wrote: >>> Nice. One-line change, I guess Aleksej would love it :-) >>> >>> On 6/7/2013 10:19 AM, Joe Darcy wrote: >>>> I'll do you one better; you can turn a negative zero into a >>>> positive zero leaving other values unchanged like this: >>>> >>>> d = d + 0.0; >>>> >>>> In IEEE 754 under the round-to-nearest-even rounding mode required >>>> by Java >>>> -0.0 + 0.0 => (+)0.0 >>>> >>>> This trick is used in various places in Java's numerical libraries, >>>> is required behavior by our specifications, and even has some tests >>>> for it :-) >>>> >>>> -Joe >>>> >>>> On 6/7/2013 8:43 AM, David Chase wrote: >>>>> Wouldn't be more efficient to do the following, assuming that the >>>>> full Java compilation chain respects the trickiness of 0 vs -0: >>>>> >>>>> if (d == 0.0) { >>>>> d=0.0 // Jam -0 == +0 to +0, per >>>>> http://www.w3.org/TR/xpath/#function-string >>>>> >>>>> } >>>>> >>>>> Division's plenty more expensive than assigning a constant, >>>>> especially on platforms that lack hardware FP division. >>>>> >>>>> David >>>>> >>>>> On 2013-06-07, at 2:03 AM, huizhe wang >>>>> wrote: >>>>> >>>>>> Hi Aleksej, >>>>>> >>>>>> According to XPath spec, both positive and negative zero are >>>>>> converted to the string 0, so it seems doesn't matter. But if you >>>>>> want to detect the negative zero, you may do the following: >>>>>> if (d == 0.0 && 1/d < 0.0) { >>>>>> d=0.0 >>>>>> } >>>>>> >>>>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >>>>>> >>>>>> -Joe >>>>> >>>> >>> >> > From alexey.utkin at oracle.com Mon Jun 10 14:05:53 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 10 Jun 2013 18:05:53 +0400 Subject: Request for review: 8016046 (process) Strict validation of input should be security manager case only [win] In-Reply-To: <51B203FF.5010604@oracle.com> References: <51B1A1C1.9000608@oracle.com> <51B203FF.5010604@oracle.com> Message-ID: <51B5DD41.1040202@oracle.com> Here is the changed version: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.01/ On 6/7/2013 8:02 PM, Alan Bateman wrote: > On 07/06/2013 10:02, Alexey Utkin wrote: >> Hi, >> Please review the fix. >> >> Bug description: >> http://bugs.sun.com/view_bug.do?bug_id=8016046 >> https://jbs.oracle.com/bugs/browse/JDK-8016046 >> >> The suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.00/ >> >> Summary: >> In absence of the Security Manager the verification procedure for >> the command-line was restored as before the JDK-8012453 fix. That >> suggests the ability of inline input/output redirection, piping, >> simultaneous launching of several programs by single command, lost >> spaces and etc. >> The extended verification procedure is activated in presence of the >> Security Manager or installing to "false" the >> "jdk.lang.Process.allowAmbiguousCommands" Java property. > Given 15 years of sloppy usage of Runtime.exec on Windows then it was > always going to be difficult to switch to tighter checking by default. > So I think the solution is right and keeps existing code working. I > also agree that it's useful to have a property to opt-in to get > property checking of the input. > > So the changes looks good to me. A minor comment on the test but in > checkOut then it could use Files.notExists. It would be useful to > expand the @bug to include the new bug ID too. Done. Regards, -uta From Alan.Bateman at oracle.com Mon Jun 10 14:15:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 15:15:14 +0100 Subject: Request for review: 8016046 (process) Strict validation of input should be security manager case only [win] In-Reply-To: <51B5DD41.1040202@oracle.com> References: <51B1A1C1.9000608@oracle.com> <51B203FF.5010604@oracle.com> <51B5DD41.1040202@oracle.com> Message-ID: <51B5DF72.3020605@oracle.com> On 10/06/2013 15:05, Alexey Utkin wrote: > Here is the changed version: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.01/ This looks good to me. -Alan From dan.xu at oracle.com Mon Jun 10 06:26:13 2013 From: dan.xu at oracle.com (Dan Xu) Date: Sun, 09 Jun 2013 23:26:13 -0700 Subject: RFR: JDK-8013827 and JDK-8011950, , java.io.File.createTempFile enters infinite loop when passed invalid data In-Reply-To: <51AC6E98.9070907@oracle.com> References: <51A4F9F5.3090909@oracle.com> <51A5EC5E.7030502@oracle.com> <51A8E8D7.9030208@oracle.com> <51A9C76E.4090101@oracle.com> <51AAAB0B.1080202@oracle.com> <51AC6E98.9070907@oracle.com> Message-ID: <51B57185.3030607@oracle.com> On 06/03/2013 03:23 AM, Alan Bateman wrote: > On 02/06/2013 03:16, Dan Xu wrote: >> : >> >> As for the SpecialTempFile testcase, I wonder whether these >> regression tests may happen to be used to test earlier JDK versions. >> In that case, the thread pool will help the test framework find the >> test failure easily. Otherwise, I agree it adds extra overhead into >> this test. > My concern is mostly the timeout as we've had so many problems with > tests failing intermittently when the machine is very busy. In this > case, I could imagine this failing when there are tests running > concurrently in a pool VMs and at the same time competing with AV > software on Windows that is sucking the life out of the system. > > In general, it's not always possible to write a test that behaves well > when run an unpatched-JDK. Deadlocks, crashes, and hangs are just some > examples where a test might timeout or jtreg needs to spin up a new VM > to continue the test execution. So while important for one-off > verification then it's probably not worth spending too much effort > trying to get it to behaves well on an JDK that doesn't have the fix. > > -Alan. Hi Alan, Thank you for the clarification. I have updated the test and "if" format at webrev, http://cr.openjdk.java.net/~dxu/8013827/webrev.02/. Please review it. -Dan From sean.coffey at oracle.com Mon Jun 10 13:00:52 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 10 Jun 2013 14:00:52 +0100 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B5B46D.8050406@oracle.com> References: <51B5B46D.8050406@oracle.com> Message-ID: <51B5CE04.5010000@oracle.com> Thanks for taking care of that Alan. Those changes look fine to me. Hope the testing works out ok. regards, Sean. On 10/06/13 12:11, Alan Bateman wrote: > > The warnings from the build of the corba repository on missing > hashCode methods have been annoying me for some time. I was hoping > they would annoy others too but looks like I blinked first :-) > > Here's the webrev with the changes that I'd like to push to fix the > issues: > > http://cr.openjdk.java.net/~alanb/8016218/webrev/ > > Note that there are 3 real issues but they are obvious. I'm running > the CORBA tests to make sure that it doesn't break anything. Note that > the bulk of the warnings were coming from ParserTable but they turn > out not to be interesting because they are only used in the testing > framework. > > -Alan. From daniel.fuchs at oracle.com Mon Jun 10 15:42:34 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Jun 2013 17:42:34 +0200 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B5B46D.8050406@oracle.com> References: <51B5B46D.8050406@oracle.com> Message-ID: <51B5F3EA.9030809@oracle.com> On 6/10/13 1:11 PM, Alan Bateman wrote: > > The warnings from the build of the corba repository on missing hashCode > methods have been annoying me for some time. I was hoping they would > annoy others too but looks like I blinked first :-) > > Here's the webrev with the changes that I'd like to push to fix the issues: > > http://cr.openjdk.java.net/~alanb/8016218/webrev/ > > Note that there are 3 real issues but they are obvious. I'm running the > CORBA tests to make sure that it doesn't break anything. Note that the > bulk of the warnings were coming from ParserTable but they turn out not > to be interesting because they are only used in the testing framework. > > -Alan. Hi Alan, Your changes look good to me. In ParserTable.java, I wonder whether it would be worth returning a different constant for each different class. best regards, -- daniel From Alan.Bateman at oracle.com Mon Jun 10 08:46:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 09:46:43 +0100 Subject: RFR 8015492: Remove DoubleStream.range methods In-Reply-To: <03F32FDB-533D-4943-A8D0-9C09E374773F@oracle.com> References: <03F32FDB-533D-4943-A8D0-9C09E374773F@oracle.com> Message-ID: <51B59273.804@oracle.com> On 03/06/2013 16:55, Paul Sandoz wrote: > Hi, > > The following patch updates DoubleStream to remove the range methods: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8015492-rm-DoubleStream.range/webrev/ > > CCC is in progress. > > It's best if we let numerical libraries integrate with the Stream API since the library writers are in a better position to design something that meets their use-cases. > > Paul. This looks fine to me. -Alan. From paul.sandoz at oracle.com Mon Jun 10 14:40:05 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 10 Jun 2013 16:40:05 +0200 Subject: 8016251: Balanced spliterator for SpinedBuffer Message-ID: Hi, This patch contains the following changes: 1) implements balanced splits for the spliterator of SpinedBuffer, which is contributed by Peter Levart; and 2) syncs lambda's version SpinedBuffer with tl, hence why there are some other changes they may not be entirely obvious until other code follows later on but will make that process easier e.g. the renaming of asXxxArray to asPrimitiveArray or the method SpinedBuffer.OfPrimitive.newArray changing from protected to public. http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/ Paul. From huizhe.wang at oracle.com Mon Jun 10 15:45:33 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jun 2013 08:45:33 -0700 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. Message-ID: <51B5F49D.9050000@oracle.com> Hi, This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for a developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ I intend to backport the change to 7u. The change will be identical. Thanks, Joe From dl at cs.oswego.edu Sun Jun 9 14:09:54 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 09 Jun 2013 10:09:54 -0400 Subject: Proposal: Comparables.isCommutativelyComparable In-Reply-To: References: <51B352C1.8050104@cs.oswego.edu> Message-ID: <51B48CB2.9030304@cs.oswego.edu> On 06/08/13 21:52, Martin Buchholz wrote: > On Sat, Jun 8, 2013 at 8:50 AM, Doug Lea
    > wrote: > > > Suppose you have two objects, x and y, both of the same > type (x.getClass() == y.getClass()) and both known > to be instanceof Comparable. > > Can you compare them? That is, can you safely call > (Comparable)x).compareTo(y); > > > Probably others tried and gave up, because you cannot actually get a reliable > answer - you can only get YES NO DUNNO, because some of the generic type > information you need may have been erased. Right, including the case where the class itself was declared with raw types. I should have stated that the method spec should say that a true return means YES, a false return means "not validated under best effort". -Doug From aleksey.shipilev at oracle.com Mon Jun 10 15:47:37 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 10 Jun 2013 19:47:37 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B39158.5000003@gmail.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> Message-ID: <51B5F519.6030307@oracle.com> On 06/09/2013 12:17 AM, Peter Levart wrote: > In case the loop retries, there's no need to construct another WeakEntry... > > T interned; > WeakEntry e = new WeakEntry<>(elem, stale); > do { > expungeStaleElements(); > WeakEntry exist = map.putIfAbsent(e, e); > interned = (exist == null)? elem: exist.get(); > } while (interned == null); > return interned; That's right, thanks! The update is here: http://cr.openjdk.java.net/~shade/7177472/webrev.02/ Testing: - Linux x86_64 builds OK - Linux x86_64 java/lang/invoke/ jtreg passes OK - The microbenchmark scores in the original note are still the same -Aleksey. From chris.hegarty at oracle.com Mon Jun 10 15:54:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Jun 2013 16:54:39 +0100 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently In-Reply-To: <51B5CBD5.8040406@oracle.com> References: <51B5CBD5.8040406@oracle.com> Message-ID: <51B5F6BF.6060704@oracle.com> I'm not sure I ever saw this test fail, but it does look like it has issues. I would much prefer to see a j.u.c.Latch/Phaser used to synchronize across these threads. -Chris. On 10/06/2013 13:51, Ivan Gerasimov wrote: > Hello everyone! > > The test of ThreadGroup.Suspend() was reported to fail on rare occasions. > It can happen on a busy machine that 1 second delay would not be enough > for the second thread to start. > Then the first thread would suspend only itself and the test would fail. > Earlier, another test was updated for similar reasons [1], [2]. > > The proposed test can still report false *positive* results if the > second thread has had no chance to execute during one second after it > had started. > To avoid them there must be a way do distinguish suspended threads. > > WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ > BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 > > > [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 > [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 > > Sincerely yours, > Ivan Gerasimov > From aleksey.shipilev at oracle.com Mon Jun 10 15:53:40 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 10 Jun 2013 19:53:40 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement Message-ID: <51B5F684.9010600@oracle.com> Hi, This is the follow-up on the issue Doug identified: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html I had reworked the patch, webrev is here: http://cr.openjdk.java.net/~shade/8016236/webrev.01/ Notable differences from Doug's version are: - handle non-generic cases as well - reuse ReflectionData to cache the interfaces and generic signatures - code style (chained ternary operators blown up) - fixes the race along the way http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6398355 Testing: - Linux x86_64/release: build OK - Linux x86_64/release: java/lang/reflect regression tests OK - Microbenchmarks show whooping increase in performance, see below (If there are no stylistic and other comments, I would like to do the JPRT submit and/or additional testing [which?]). The benchmark is here (you need JMH to build and run): http://cr.openjdk.java.net/~shade/8016236/classbench.zip Before: > Benchmark Mode Thr Cnt Sec Mean Mean error Units > o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 326.835 1.220 nsec/op > o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 308.793 2.828 nsec/op > o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 312.627 1.637 nsec/op > o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 216.983 8.902 nsec/op > o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 59.933 0.183 nsec/op > o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 65.469 0.284 nsec/op Doug's version: > Benchmark Mode Thr Cnt Sec Mean Mean error Units > o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 15.106 0.271 nsec/op > o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.304 0.024 nsec/op > o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.739 0.045 nsec/op > o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 213.825 1.346 nsec/op > o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 61.651 0.394 nsec/op > o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 64.340 0.522 nsec/op After: > Benchmark Mode Thr Cnt Sec Mean Mean error Units > o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 14.985 0.104 nsec/op > o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op > o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.874 0.175 nsec/op > o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 23.941 0.177 nsec/op > o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 8.583 0.044 nsec/op > o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 12.400 0.045 nsec/op Thanks, Aleksey. From Alan.Bateman at oracle.com Mon Jun 10 10:31:38 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 11:31:38 +0100 Subject: 8016217: More javadoc warnings Message-ID: <51B5AB0A.4010408@oracle.com> About 8 months ago I tried an early build of doclint [1] and used it to fix up a bunch issues at the time [2]. It's been awhile, so I decided to try out the latest version to see how it has progressed. All I can say is "Yikes". The good news is that they reported against the original source and that makes it easy when compared to tools that validate the generated html. I decided to fix up a few issues, mostly syntax (escaping of > and < in particular) and a few reference issues that were missed the last time (or are new). There are thousands of other issues for anyone that wants to jump in. I've put the webrev with the changes here: http://cr.openjdk.java.net/~alanb/8016217/webrev/ In total this fixes ~500 issues, although 270 of those were coming from java.sql.DatabaseMetaData due to the number of un-escaped usages of "=>". In many cases, the changes are simply to use {@code ..} or replace with {@code ...}. It is tempting to just do a global replace on existing usages (would fixing up content that is escaped of course). I've run specdiff on the before & after to check that I didn't mess anything up. One obvious difference is that code examples that use generics now have the type parameters going through to the generated javadoc. The webrev touches many areas but as the changes are trivial, I don't need a reviewer from every area. -Alan. [1] http://openjdk.java.net/jeps/172 [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 From pbenedict at apache.org Mon Jun 10 14:09:41 2013 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 10 Jun 2013 09:09:41 -0500 Subject: Proposal: Comparables.isCommutativelyComparable Message-ID: I like the idea except for the overly-elongated name. I think isCommunicative would suffice. Paul From alexey.utkin at oracle.com Mon Jun 10 08:15:03 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 10 Jun 2013 12:15:03 +0400 Subject: Request for review: 8016046 (process) Strict validation of input should be security manager case only [win] In-Reply-To: <51B203FF.5010604@oracle.com> References: <51B1A1C1.9000608@oracle.com> <51B203FF.5010604@oracle.com> Message-ID: <51B58B07.3070502@oracle.com> Here is the changed version: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.01/ On 6/7/2013 8:02 PM, Alan Bateman wrote: > On 07/06/2013 10:02, Alexey Utkin wrote: >> Hi, >> Please review the fix. >> >> Bug description: >> http://bugs.sun.com/view_bug.do?bug_id=8016046 >> https://jbs.oracle.com/bugs/browse/JDK-8016046 >> >> The suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8016046/webrev.00/ >> >> Summary: >> In absence of the Security Manager the verification procedure for >> the command-line was restored as before the JDK-8012453 fix. That >> suggests the ability of inline input/output redirection, piping, >> simultaneous launching of several programs by single command, lost >> spaces and etc. >> The extended verification procedure is activated in presence of the >> Security Manager or installing to "false" the >> "jdk.lang.Process.allowAmbiguousCommands" Java property. > Given 15 years of sloppy usage of Runtime.exec on Windows then it was > always going to be difficult to switch to tighter checking by default. > So I think the solution is right and keeps existing code working. I > also agree that it's useful to have a property to opt-in to get > property checking of the input. > > So the changes looks good to me. A minor comment on the test but in > checkOut then it could use Files.notExists. It would be useful to > expand the @bug to include the new bug ID too. Done. Regards, -uta From joe.darcy at oracle.com Sun Jun 9 18:23:38 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 09 Jun 2013 11:23:38 -0700 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B4C6F0.509@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> <51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com> <51B4C6F0.509@oracle.com> Message-ID: <51B4C82A.7070807@oracle.com> Hello Aleksej, Looking at the code, I have another suggestion. If this code can run exclusively on JDK 8 or later, replace 955 if (Double.isNaN(d) || Double.isInfinite(d)) 956 return(Double.toString(d)); with 955 if (!Double.isFinite(d)) 956 return(Double.toString(d)); Cheers, -Joe On 6/9/2013 11:18 AM, Aleksej Efimov wrote: > Joe, > > I definitely like it: > 1. Its a one-line change - perfect size. > 2. Its fastest one from discussed previously. > 3. -0.0 -> 0.0 has tests. > 4. And it solves our problem. > > As a result of all props the next version of webrev: > http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ > > > Thanks > -Aleksej > > On 06/07/2013 11:11 PM, huizhe wang wrote: >> Nice. One-line change, I guess Aleksej would love it :-) >> >> On 6/7/2013 10:19 AM, Joe Darcy wrote: >>> I'll do you one better; you can turn a negative zero into a positive >>> zero leaving other values unchanged like this: >>> >>> d = d + 0.0; >>> >>> In IEEE 754 under the round-to-nearest-even rounding mode required >>> by Java >>> -0.0 + 0.0 => (+)0.0 >>> >>> This trick is used in various places in Java's numerical libraries, >>> is required behavior by our specifications, and even has some tests >>> for it :-) >>> >>> -Joe >>> >>> On 6/7/2013 8:43 AM, David Chase wrote: >>>> Wouldn't be more efficient to do the following, assuming that the >>>> full Java compilation chain respects the trickiness of 0 vs -0: >>>> >>>> if (d == 0.0) { >>>> d=0.0 // Jam -0 == +0 to +0, per >>>> http://www.w3.org/TR/xpath/#function-string >>>> >>>> } >>>> >>>> Division's plenty more expensive than assigning a constant, >>>> especially on platforms that lack hardware FP division. >>>> >>>> David >>>> >>>> On 2013-06-07, at 2:03 AM, huizhe wang wrote: >>>> >>>>> Hi Aleksej, >>>>> >>>>> According to XPath spec, both positive and negative zero are >>>>> converted to the string 0, so it seems doesn't matter. But if you >>>>> want to detect the negative zero, you may do the following: >>>>> if (d == 0.0 && 1/d < 0.0) { >>>>> d=0.0 >>>>> } >>>>> >>>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >>>>> >>>>> -Joe >>>> >>> >> > From chris.hegarty at oracle.com Mon Jun 10 11:22:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Jun 2013 12:22:41 +0100 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B5B46D.8050406@oracle.com> References: <51B5B46D.8050406@oracle.com> Message-ID: <51B5B701.5060408@oracle.com> All look good to me. These, hashCode/equals, warning have been annoying me for a while now too, but I have yet to blink! -Chris. On 10/06/2013 12:11, Alan Bateman wrote: > > The warnings from the build of the corba repository on missing hashCode > methods have been annoying me for some time. I was hoping they would > annoy others too but looks like I blinked first :-) > > Here's the webrev with the changes that I'd like to push to fix the issues: > > http://cr.openjdk.java.net/~alanb/8016218/webrev/ > > Note that there are 3 real issues but they are obvious. I'm running the > CORBA tests to make sure that it doesn't break anything. Note that the > bulk of the warnings were coming from ParserTable but they turn out not > to be interesting because they are only used in the testing framework. > > -Alan. From Alan.Bateman at oracle.com Mon Jun 10 11:11:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 12:11:41 +0100 Subject: 8016218: Warnings building corba repo due to missing hashCode methods Message-ID: <51B5B46D.8050406@oracle.com> The warnings from the build of the corba repository on missing hashCode methods have been annoying me for some time. I was hoping they would annoy others too but looks like I blinked first :-) Here's the webrev with the changes that I'd like to push to fix the issues: http://cr.openjdk.java.net/~alanb/8016218/webrev/ Note that there are 3 real issues but they are obvious. I'm running the CORBA tests to make sure that it doesn't break anything. Note that the bulk of the warnings were coming from ParserTable but they turn out not to be interesting because they are only used in the testing framework. -Alan. From aleksej.efimov at oracle.com Sun Jun 9 18:18:24 2013 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Sun, 09 Jun 2013 22:18:24 +0400 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B23070.6020006@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> <51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com> Message-ID: <51B4C6F0.509@oracle.com> Joe, I definitely like it: 1. Its a one-line change - perfect size. 2. Its fastest one from discussed previously. 3. -0.0 -> 0.0 has tests. 4. And it solves our problem. As a result of all props the next version of webrev: http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ Thanks -Aleksej On 06/07/2013 11:11 PM, huizhe wang wrote: > Nice. One-line change, I guess Aleksej would love it :-) > > On 6/7/2013 10:19 AM, Joe Darcy wrote: >> I'll do you one better; you can turn a negative zero into a positive >> zero leaving other values unchanged like this: >> >> d = d + 0.0; >> >> In IEEE 754 under the round-to-nearest-even rounding mode required by >> Java >> -0.0 + 0.0 => (+)0.0 >> >> This trick is used in various places in Java's numerical libraries, >> is required behavior by our specifications, and even has some tests >> for it :-) >> >> -Joe >> >> On 6/7/2013 8:43 AM, David Chase wrote: >>> Wouldn't be more efficient to do the following, assuming that the >>> full Java compilation chain respects the trickiness of 0 vs -0: >>> >>> if (d == 0.0) { >>> d=0.0 // Jam -0 == +0 to +0, per >>> http://www.w3.org/TR/xpath/#function-string >>> >>> } >>> >>> Division's plenty more expensive than assigning a constant, >>> especially on platforms that lack hardware FP division. >>> >>> David >>> >>> On 2013-06-07, at 2:03 AM, huizhe wang wrote: >>> >>>> Hi Aleksej, >>>> >>>> According to XPath spec, both positive and negative zero are >>>> converted to the string 0, so it seems doesn't matter. But if you >>>> want to detect the negative zero, you may do the following: >>>> if (d == 0.0 && 1/d < 0.0) { >>>> d=0.0 >>>> } >>>> >>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >>>> >>>> -Joe >>> >> > From chris.hegarty at oracle.com Mon Jun 10 11:17:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Jun 2013 12:17:42 +0100 Subject: 8016217: More javadoc warnings In-Reply-To: <51B5AB0A.4010408@oracle.com> References: <51B5AB0A.4010408@oracle.com> Message-ID: <51B5B5D6.8050905@oracle.com> I eyeballed the patch file. Looks fine to me. It is really nice to have a tool to that operates on the actual source. -Chris. On 10/06/2013 11:31, Alan Bateman wrote: > > About 8 months ago I tried an early build of doclint [1] and used it to > fix up a bunch issues at the time [2]. It's been awhile, so I decided to > try out the latest version to see how it has progressed. All I can say > is "Yikes". The good news is that they reported against the original > source and that makes it easy when compared to tools that validate the > generated html. > > I decided to fix up a few issues, mostly syntax (escaping of > and < in > particular) and a few reference issues that were missed the last time > (or are new). There are thousands of other issues for anyone that wants > to jump in. > > I've put the webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/8016217/webrev/ > > In total this fixes ~500 issues, although 270 of those were coming from > java.sql.DatabaseMetaData due to the number of un-escaped usages of > "=>". In many cases, the changes are simply to use {@code ..} or replace > with {@code ...}. It is tempting to just do a global replace on > existing usages (would fixing up content that is escaped > of course). > > I've run specdiff on the before & after to check that I didn't mess > anything up. One obvious difference is that code examples that use > generics now have the type parameters going through to the generated > javadoc. > > The webrev touches many areas but as the changes are trivial, I don't > need a reviewer from every area. > > -Alan. > > [1] http://openjdk.java.net/jeps/172 > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 From huizhe.wang at oracle.com Sat Jun 8 20:11:24 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Sat, 08 Jun 2013 13:11:24 -0700 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. Message-ID: <51B38FEC.6090000@oracle.com> Hi, This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for the developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ I intend to backport the change to 7u. The change will be identical. Thanks, Joe From Lance.Andersen at oracle.com Mon Jun 10 11:02:20 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 10 Jun 2013 07:02:20 -0400 Subject: 8016217: More javadoc warnings In-Reply-To: <51B5AB0A.4010408@oracle.com> References: <51B5AB0A.4010408@oracle.com> Message-ID: <7D2F7E57-3585-4818-BF2E-D9E7940B29C5@oracle.com> This looks good. Thank you for taking this on Alan. Best Lance On Jun 10, 2013, at 6:31 AM, Alan Bateman wrote: > > About 8 months ago I tried an early build of doclint [1] and used it to fix up a bunch issues at the time [2]. It's been awhile, so I decided to try out the latest version to see how it has progressed. All I can say is "Yikes". The good news is that they reported against the original source and that makes it easy when compared to tools that validate the generated html. > > I decided to fix up a few issues, mostly syntax (escaping of > and < in particular) and a few reference issues that were missed the last time (or are new). There are thousands of other issues for anyone that wants to jump in. > > I've put the webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/8016217/webrev/ > > In total this fixes ~500 issues, although 270 of those were coming from java.sql.DatabaseMetaData due to the number of un-escaped usages of "=>". In many cases, the changes are simply to use {@code ..} or replace with {@code ...}. It is tempting to just do a global replace on existing usages (would fixing up content that is escaped of course). > > I've run specdiff on the before & after to check that I didn't mess anything up. One obvious difference is that code examples that use generics now have the type parameters going through to the generated javadoc. > > The webrev touches many areas but as the changes are trivial, I don't need a reviewer from every area. > > -Alan. > > [1] http://openjdk.java.net/jeps/172 > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Mon Jun 10 16:30:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Jun 2013 09:30:11 -0700 Subject: RFR 8015978: Incorrect transformation of XPath expression "string(-0)" In-Reply-To: <51B5EA87.6090705@oracle.com> References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com> <51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com> <51B4C6F0.509@oracle.com> <51B4C82A.7070807@oracle.com> <51B5EA87.6090705@oracle.com> Message-ID: <51B5FF13.9000802@oracle.com> Hi Aleksej, On 6/10/2013 8:02 AM, Aleksej Efimov wrote: > Hi Joe, > We can replace the "Double.isNaN(d) || Double.isInfinite(d)" with > "!Double.isFinite(d)" - I agree that this one check looks better, but > we still need to do the -0.0 -> 0.0 conversion to solve the reported > problem. And as I understand (might be wrong) modification of this > check won't help us to achieve this goal, we still need to do the > conversion: > + //Convert -0.0 to +0.0 other values remains the same > + d = d + 0.0; > + Right; changing the set of Double.isFoo methods called earlier doesn't change the need for the (d + 0.0) expression. I just noticed the double isFoo calls when looking at the code and saw an opportunity to use the new method. Cheers, -Joe > Regards, > -Aleksej > > On 06/09/2013 10:23 PM, Joe Darcy wrote: >> Hello Aleksej, >> >> Looking at the code, I have another suggestion. If this code can run >> exclusively on JDK 8 or later, replace >> >> 955 if (Double.isNaN(d) || Double.isInfinite(d)) >> 956 return(Double.toString(d)); >> >> with >> >> 955 if (!Double.isFinite(d)) >> 956 return(Double.toString(d)); >> >> Cheers, >> >> -Joe >> >> On 6/9/2013 11:18 AM, Aleksej Efimov wrote: >>> Joe, >>> >>> I definitely like it: >>> 1. Its a one-line change - perfect size. >>> 2. Its fastest one from discussed previously. >>> 3. -0.0 -> 0.0 has tests. >>> 4. And it solves our problem. >>> >>> As a result of all props the next version of webrev: >>> http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ >>> >>> >>> Thanks >>> -Aleksej >>> >>> On 06/07/2013 11:11 PM, huizhe wang wrote: >>>> Nice. One-line change, I guess Aleksej would love it :-) >>>> >>>> On 6/7/2013 10:19 AM, Joe Darcy wrote: >>>>> I'll do you one better; you can turn a negative zero into a >>>>> positive zero leaving other values unchanged like this: >>>>> >>>>> d = d + 0.0; >>>>> >>>>> In IEEE 754 under the round-to-nearest-even rounding mode required >>>>> by Java >>>>> -0.0 + 0.0 => (+)0.0 >>>>> >>>>> This trick is used in various places in Java's numerical >>>>> libraries, is required behavior by our specifications, and even >>>>> has some tests for it :-) >>>>> >>>>> -Joe >>>>> >>>>> On 6/7/2013 8:43 AM, David Chase wrote: >>>>>> Wouldn't be more efficient to do the following, assuming that the >>>>>> full Java compilation chain respects the trickiness of 0 vs -0: >>>>>> >>>>>> if (d == 0.0) { >>>>>> d=0.0 // Jam -0 == +0 to +0, per >>>>>> http://www.w3.org/TR/xpath/#function-string >>>>>> >>>>>> } >>>>>> >>>>>> Division's plenty more expensive than assigning a constant, >>>>>> especially on platforms that lack hardware FP division. >>>>>> >>>>>> David >>>>>> >>>>>> On 2013-06-07, at 2:03 AM, huizhe wang >>>>>> wrote: >>>>>> >>>>>>> Hi Aleksej, >>>>>>> >>>>>>> According to XPath spec, both positive and negative zero are >>>>>>> converted to the string 0, so it seems doesn't matter. But if >>>>>>> you want to detect the negative zero, you may do the following: >>>>>>> if (d == 0.0 && 1/d < 0.0) { >>>>>>> d=0.0 >>>>>>> } >>>>>>> >>>>>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity). >>>>>>> >>>>>>> -Joe >>>>>> >>>>> >>>> >>> >> > From paul.sandoz at oracle.com Mon Jun 10 16:44:37 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 10 Jun 2013 18:44:37 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B5F684.9010600@oracle.com> References: <51B5F684.9010600@oracle.com> Message-ID: <3FDC74A9-6063-4019-A18F-66AD6F515A0D@oracle.com> On Jun 10, 2013, at 5:53 PM, Aleksey Shipilev wrote: > Hi, > > This is the follow-up on the issue Doug identified: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html > > I had reworked the patch, webrev is here: > http://cr.openjdk.java.net/~shade/8016236/webrev.01/ > > Notable differences from Doug's version are: > - handle non-generic cases as well I was wondering about that case too. > - reuse ReflectionData to cache the interfaces and generic signatures Any guess on the size impact due to those new fields in ReflectionData? > - code style (chained ternary operators blown up) > - fixes the race along the way > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6398355 > > Testing: > - Linux x86_64/release: build OK > - Linux x86_64/release: java/lang/reflect regression tests OK > - Microbenchmarks show whooping increase in performance, see below > Nice improvements. Paul. > (If there are no stylistic and other comments, I would like to do the > JPRT submit and/or additional testing [which?]). > > The benchmark is here (you need JMH to build and run): > http://cr.openjdk.java.net/~shade/8016236/classbench.zip > > Before: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 326.835 1.220 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 308.793 2.828 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 312.627 1.637 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 216.983 8.902 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 59.933 0.183 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 65.469 0.284 nsec/op > > Doug's version: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 15.106 0.271 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.304 0.024 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.739 0.045 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 213.825 1.346 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 61.651 0.394 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 64.340 0.522 nsec/op > > After: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 14.985 0.104 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.874 0.175 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 23.941 0.177 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 8.583 0.044 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 12.400 0.045 nsec/op > > Thanks, > Aleksey. From Alan.Bateman at oracle.com Mon Jun 10 16:44:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 17:44:49 +0100 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B5F3EA.9030809@oracle.com> References: <51B5B46D.8050406@oracle.com> <51B5F3EA.9030809@oracle.com> Message-ID: <51B60281.70902@oracle.com> On 10/06/2013 16:42, Daniel Fuchs wrote: > : > > In ParserTable.java, I wonder whether it would be worth > returning a different constant for each different class. I could although I don't think they are used (and probably could be deleted). -Alan. From Lance.Andersen at oracle.com Mon Jun 10 16:44:43 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 10 Jun 2013 12:44:43 -0400 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: <51B38FEC.6090000@oracle.com> References: <51B38FEC.6090000@oracle.com> Message-ID: looks fine joe -lance On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: > Hi, > > This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for the developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ > > I intend to backport the change to 7u. The change will be identical. > > Thanks, > Joe -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From alan.bateman at oracle.com Mon Jun 10 16:45:25 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Jun 2013 16:45:25 +0000 Subject: hg: jdk8/tl/corba: 8016218: Warnings building corba repo due to missing hashCode methods Message-ID: <20130610164527.1CE8048101@hg.openjdk.java.net> Changeset: 5845df371e25 Author: alanb Date: 2013-06-10 17:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5845df371e25 8016218: Warnings building corba repo due to missing hashCode methods Reviewed-by: chegar, coffeys, dfuchs ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java From peter.levart at gmail.com Sat Jun 8 20:29:10 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 08 Jun 2013 22:29:10 +0200 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B3932F.5090802@gmail.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B3932F.5090802@gmail.com> Message-ID: <51B39416.10009@gmail.com> On 06/08/2013 10:25 PM, Peter Levart wrote: > > On 06/08/2013 10:17 PM, Peter Levart wrote: >> >> On 06/08/2013 12:21 PM, Remi Forax wrote: >>> On 06/07/2013 12:01 PM, Aleksey Shipilev wrote: >>>> (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as >>>> Christian T. >>>> suggested offline) >>>> >>>> Hi guys, >>> >>> Hi Aleksey, >>> >>>> >>>> The fix for scalability problem is here: >>>> http://cr.openjdk.java.net/~shade/7177472/webrev.00/ >>> >>> in add, the do/while does something a little weird, if putIfAbsent >>> returns null, >>> interned is equals to elem, there is no need to do a e.get() in that >>> case, >>> I would prefer a code like this: >>> >>> T interned; >>> do { >>> expungeStaleElements(); >>> WeakEntry e = new WeakEntry<>(elem, stale); >>> WeakEntry exist = map.putIfAbsent(e, e); >>> interned = (exist == null)? elem: exist.get(); >>> } while (interned == null); >>> return interned; >> >> Hi Remi, Aleksey, >> >> In case the loop retries, there's no need to construct another >> WeakEntry... >> >> T interned; >> WeakEntry e = new WeakEntry<>(elem, stale); >> do { >> expungeStaleElements(); >> WeakEntry exist = map.putIfAbsent(e, e); >> interned = (exist == null)? elem: exist.get(); >> } while (interned == null); >> return interned; >> >> Regards, Peter > > Aleksey, > > Also, in a retry-loop you might be spin-waiting for the > ReferenceHandler thread to transfer the cleared WeakEntry to the > ReferenceQueue. You might want to do a map.replace(e, exist, e) in > case exist != null and exist.get() == null to make it independent of > ReferenceHandler thread's processing. In this case only a single > out-of-loop call to expungeStaleElements() would be enough. Scrap that. when exist.get() == null, exist.equals(e) == false, so putIfAbsent should succeed. > > Peter > >> >>> >>> The cast to WeakEntry in expungeStaleElements is not needed. >>> >>> In WeakEntry.equals, the null check is not needed because null >>> instanceof WeakEntry returns false, >>> and you don't need to cast obj.get() to a WeakEntry given you >>> only to call equals on entry.get(). >>> So the code should be: >>> >>> >>> public boolean equals(Object obj) { >>> if (!(obj instanceof WeakEntry)) { >>> return false; >>> } >>> Object that = ((WeakEntry)obj).get(); >>> Object mine = get(); >>> return (that == null || mine == null)? this == obj: >>> mine.equals(that); >>> } >>> >>> >>> Otherwise, it looks good. >>> >>> R?mi >>> >>>> >>>> Testing: >>>> - Linux x86_64 builds OK >>>> - Linux x86_64 java/lang/invoke/ jtreg passes OK >>>> >>>> Since this is a proof-of-concept patch at this point, I kept the >>>> testing >>>> minimal. Let me know what other testing you think is needed before the >>>> integration. >>>> >>>> Thanks, >>>> Aleksey. >>>> >>>> *** Rationale and details for the issue follow: *** >>>> >>>> This issue was in limbo for an year. The performance issue with >>>> MethodType.methodType factory leads to abysmal scalability on the >>>> targeted tests. While this can arguably demonstrated on larger >>>> workloads, the targeted microbenchmarks are showcasing it nicely. This >>>> issue was blocking the JSR292 API performance testing, because on >>>> large >>>> enough test server, you will inevitably be bitten by this. >>>> >>>> If you run the JMH-enabled [1] microbenchmark: >>>> http://openjdk.java.net/projects/code-tools/jmh/ >>>> http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz >>>> >>>> ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will >>>> see >>>> the scalability is going down. ("testCached" makes sure the >>>> reference to >>>> MethodType is always strongly reachable, "testNew" makes sure the >>>> reference is mostly non-reachable, prompting cache re-fill, "testOOB" >>>> does not make any precautions about that, and also does not suffer >>>> from >>>> the static overheads entailed by the reference management in first two >>>> tests). >>>> >>>> 1 thread: >>>> MethodTypeBench.testCached 78 +- 1 nsec/op >>>> MethodTypeBench.testNew 120 +- 1 nsec/op >>>> MethodTypeBench.testOOB 41 +- 1 nsec/op >>>> >>>> 4 threads: >>>> MethodTypeBench.testCached 495 +- 40 nsec/op >>>> MethodTypeBench.testNew 611 +- 37 nsec/op >>>> MethodTypeBench.testOOB 377 +- 10 nsec/op >>>> >>>> In fact, on larger machines it may be as bad as tens/hundreds of >>>> microseconds to look up the MethodType. With the patch applied, on the >>>> same 2x2 machine: >>>> >>>> 1 thread: >>>> MethodTypeBench.testCached 92 +- 1 nsec/op >>>> MethodTypeBench.testNew 101 +- 1 nsec/op >>>> MethodTypeBench.testOOB 49 +- 1 nsec/op >>>> >>>> 4 threads: >>>> MethodTypeBench.testCached 129 +- 1 nsec/op >>>> MethodTypeBench.testNew 142 +- 10 nsec/op >>>> MethodTypeBench.testOOB 89 +- 3 nsec/op >>>> >>>> >>>> ...which means the scalability is back: the average time to look up >>>> the >>>> MethodType is not growing spectacularly when the thread count go up. >>>> Again, the effect is astonishing on large machines. >>>> >>>> Notice that we took some hit in single-threaded performance, and >>>> that is >>>> due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the >>>> upcoming CHMv8, this starts to look better: >>>> >>>> 1 thread: >>>> MethodTypeBench.testCached 87 +- 1 nsec/op >>>> MethodTypeBench.testNew 95 +- 1 nsec/op >>>> MethodTypeBench.testOOB 52 +- 1 nsec/op >>>> >>>> 4 threads: >>>> MethodTypeBench.testCached 121 +- 2 nsec/op >>>> MethodTypeBench.testNew 141 +- 1 nsec/op >>>> MethodTypeBench.testOOB 93 +- 5 nsec/op >>>> >>>> ...which seems to indicate this change is future-proof. >>> >> > From aleksey.shipilev at oracle.com Sat Jun 8 19:51:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 8 Jun 2013 23:51:27 +0400 Subject: Proposal: Comparables.isCommutativelyComparable In-Reply-To: <51B352C1.8050104@cs.oswego.edu> References: <51B352C1.8050104@cs.oswego.edu> Message-ID: <52090F79-EA44-49A9-83FF-131F9CB9B103@oracle.com> Hm, sounds interesting. What's about yet another "factory"-like default in Comparator: Comparator Comparator.make(Class klass) - returns synthetic comparator using C.compareTo iff C implements Comparable - returns null otherwise That will naively instantiate the Comparator, but there is the possibility to reuse e.g. ClassValue to lazily associate the default comparator with the class. -Aleksey. On 08.06.2013, at 19:50, Doug Lea
    wrote: > > Suppose you have two objects, x and y, both of the same > type (x.getClass() == y.getClass()) and both known > to be instanceof Comparable. > > Can you compare them? That is, can you safely call > (Comparable)x).compareTo(y); > > Almost always, the answer is yes, because almost all > Comparable classes are of form "class C implements Comparable" > > But there's nothing about interface Comparable that forces > this to be true. It would be weird but legal if both > are of form, say, "class C implements Comparable". > Which means that you cannot compare them to each other. > > There's currently no direct way to check if you have a normal > commutative (bidirectionally applicable) pair of comparables. > > It can be checked using reflection though, using mechanics > that are both messy and slower than they might be if > implemented as a JDK utility method. > > There a few possible API choices for how to do this. > > The most basic is > > boolean isCommutativelyComparable(Class c); > > returning true if c represents a class form C implements Comparable. > (It would be OK although a little annoying to use if it restricted > argument type to Class>.) > > A more general one is: > > Class commutativelyComparableClassFor(Object x) > > that returns a class C such that > (x instanceof C) and (C implements Comparable) > or null if there is no such class. The return type could > be strengthened to Class> > > This allows use of the result to match up objects of > subclasses of commutatively comparable classes. > > The most handy form is: > > int compareIfCommutativelyComparable(Comparable x, Comparable y); > > that returns compareTo result if both of same commutatively > comparable type, else 0. > > Maybe this one is *too* handy though. It's not hard to > get the same effect manually given the above methods. > > Does anyone have any thoughts about introducing at > least the first, and possibly the others into the > java.util.Comparables utility class? If so, there would > be a few immediate usages within JDK. > > I'm surprised that this hasn't come up for consideration > before. Or maybe I haven't noticed previous discussions? > > -Doug > > > From peter.levart at gmail.com Sat Jun 8 20:25:19 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 08 Jun 2013 22:25:19 +0200 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B39158.5000003@gmail.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> Message-ID: <51B3932F.5090802@gmail.com> On 06/08/2013 10:17 PM, Peter Levart wrote: > > On 06/08/2013 12:21 PM, Remi Forax wrote: >> On 06/07/2013 12:01 PM, Aleksey Shipilev wrote: >>> (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as >>> Christian T. >>> suggested offline) >>> >>> Hi guys, >> >> Hi Aleksey, >> >>> >>> The fix for scalability problem is here: >>> http://cr.openjdk.java.net/~shade/7177472/webrev.00/ >> >> in add, the do/while does something a little weird, if putIfAbsent >> returns null, >> interned is equals to elem, there is no need to do a e.get() in that >> case, >> I would prefer a code like this: >> >> T interned; >> do { >> expungeStaleElements(); >> WeakEntry e = new WeakEntry<>(elem, stale); >> WeakEntry exist = map.putIfAbsent(e, e); >> interned = (exist == null)? elem: exist.get(); >> } while (interned == null); >> return interned; > > Hi Remi, Aleksey, > > In case the loop retries, there's no need to construct another > WeakEntry... > > T interned; > WeakEntry e = new WeakEntry<>(elem, stale); > do { > expungeStaleElements(); > WeakEntry exist = map.putIfAbsent(e, e); > interned = (exist == null)? elem: exist.get(); > } while (interned == null); > return interned; > > Regards, Peter Aleksey, Also, in a retry-loop you might be spin-waiting for the ReferenceHandler thread to transfer the cleared WeakEntry to the ReferenceQueue. You might want to do a map.replace(e, exist, e) in case exist != null and exist.get() == null to make it independent of ReferenceHandler thread's processing. In this case only a single out-of-loop call to expungeStaleElements() would be enough. Peter > >> >> The cast to WeakEntry in expungeStaleElements is not needed. >> >> In WeakEntry.equals, the null check is not needed because null >> instanceof WeakEntry returns false, >> and you don't need to cast obj.get() to a WeakEntry given you only >> to call equals on entry.get(). >> So the code should be: >> >> >> public boolean equals(Object obj) { >> if (!(obj instanceof WeakEntry)) { >> return false; >> } >> Object that = ((WeakEntry)obj).get(); >> Object mine = get(); >> return (that == null || mine == null)? this == obj: >> mine.equals(that); >> } >> >> >> Otherwise, it looks good. >> >> R?mi >> >>> >>> Testing: >>> - Linux x86_64 builds OK >>> - Linux x86_64 java/lang/invoke/ jtreg passes OK >>> >>> Since this is a proof-of-concept patch at this point, I kept the >>> testing >>> minimal. Let me know what other testing you think is needed before the >>> integration. >>> >>> Thanks, >>> Aleksey. >>> >>> *** Rationale and details for the issue follow: *** >>> >>> This issue was in limbo for an year. The performance issue with >>> MethodType.methodType factory leads to abysmal scalability on the >>> targeted tests. While this can arguably demonstrated on larger >>> workloads, the targeted microbenchmarks are showcasing it nicely. This >>> issue was blocking the JSR292 API performance testing, because on large >>> enough test server, you will inevitably be bitten by this. >>> >>> If you run the JMH-enabled [1] microbenchmark: >>> http://openjdk.java.net/projects/code-tools/jmh/ >>> http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz >>> >>> ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will see >>> the scalability is going down. ("testCached" makes sure the >>> reference to >>> MethodType is always strongly reachable, "testNew" makes sure the >>> reference is mostly non-reachable, prompting cache re-fill, "testOOB" >>> does not make any precautions about that, and also does not suffer from >>> the static overheads entailed by the reference management in first two >>> tests). >>> >>> 1 thread: >>> MethodTypeBench.testCached 78 +- 1 nsec/op >>> MethodTypeBench.testNew 120 +- 1 nsec/op >>> MethodTypeBench.testOOB 41 +- 1 nsec/op >>> >>> 4 threads: >>> MethodTypeBench.testCached 495 +- 40 nsec/op >>> MethodTypeBench.testNew 611 +- 37 nsec/op >>> MethodTypeBench.testOOB 377 +- 10 nsec/op >>> >>> In fact, on larger machines it may be as bad as tens/hundreds of >>> microseconds to look up the MethodType. With the patch applied, on the >>> same 2x2 machine: >>> >>> 1 thread: >>> MethodTypeBench.testCached 92 +- 1 nsec/op >>> MethodTypeBench.testNew 101 +- 1 nsec/op >>> MethodTypeBench.testOOB 49 +- 1 nsec/op >>> >>> 4 threads: >>> MethodTypeBench.testCached 129 +- 1 nsec/op >>> MethodTypeBench.testNew 142 +- 10 nsec/op >>> MethodTypeBench.testOOB 89 +- 3 nsec/op >>> >>> >>> ...which means the scalability is back: the average time to look up the >>> MethodType is not growing spectacularly when the thread count go up. >>> Again, the effect is astonishing on large machines. >>> >>> Notice that we took some hit in single-threaded performance, and >>> that is >>> due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the >>> upcoming CHMv8, this starts to look better: >>> >>> 1 thread: >>> MethodTypeBench.testCached 87 +- 1 nsec/op >>> MethodTypeBench.testNew 95 +- 1 nsec/op >>> MethodTypeBench.testOOB 52 +- 1 nsec/op >>> >>> 4 threads: >>> MethodTypeBench.testCached 121 +- 2 nsec/op >>> MethodTypeBench.testNew 141 +- 1 nsec/op >>> MethodTypeBench.testOOB 93 +- 5 nsec/op >>> >>> ...which seems to indicate this change is future-proof. >> > From aleksey.shipilev at oracle.com Mon Jun 10 17:20:06 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 10 Jun 2013 21:20:06 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <3FDC74A9-6063-4019-A18F-66AD6F515A0D@oracle.com> References: <51B5F684.9010600@oracle.com> <3FDC74A9-6063-4019-A18F-66AD6F515A0D@oracle.com> Message-ID: <51B60AC6.3030407@oracle.com> Thanks for taking a look, Paul! Can I count your review as official? On 06/10/2013 08:44 PM, Paul Sandoz wrote: >> - reuse ReflectionData to cache the interfaces and generic signatures > > Any guess on the size impact due to those new fields in ReflectionData? Seems to be additional 16 bytes (boolean+oop+oop+alignment, see below); again, since the ReflectionData is lazily-constructed, this is not the issue for most of the classes. ---- Before: Running 64-bit HotSpot VM. Using compressed references with 3-bit shift. Objects are 8 bytes aligned. java.lang.Class.ReflectionData offset size type description 0 12 (assumed to be the object header) 12 4 int ReflectionData.redefinedCount 16 4 Field[] ReflectionData.declaredFields 20 4 Field[] ReflectionData.publicFields 24 4 Method[] ReflectionData.declaredMethods 28 4 Method[] ReflectionData.publicMethods 32 4 Constructor[] ReflectionData.declaredConstructors 36 4 Constructor[] ReflectionData.publicConstructors 40 4 Field[] ReflectionData.declaredPublicFields 44 4 Method[] ReflectionData.declaredPublicMethods 48 (object boundary, size estimate) ---- After: Running 64-bit HotSpot VM. Using compressed references with 3-bit shift. Objects are 16 bytes aligned. java.lang.Class.ReflectionData offset size type description 0 12 (assumed to be the object header) 12 4 int ReflectionData.redefinedCount 16 1 boolean ReflectionData.genericSignatureResolved 17 3 (alignment/padding gap) 20 4 Field[] ReflectionData.declaredFields 24 4 Field[] ReflectionData.publicFields 28 4 Method[] ReflectionData.declaredMethods 32 4 Method[] ReflectionData.publicMethods 36 4 Constructor[] ReflectionData.declaredConstructors 40 4 Constructor[] ReflectionData.publicConstructors 44 4 Field[] ReflectionData.declaredPublicFields 48 4 Method[] ReflectionData.declaredPublicMethods 52 4 Class[] ReflectionData.interfaces 56 4 String ReflectionData.genericSignature 60 4 (loss due to the next object alignment) 64 (object boundary, size estimate) From martinrb at google.com Sun Jun 9 01:20:54 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 8 Jun 2013 18:20:54 -0700 Subject: Proposal: Comparables.isCommutativelyComparable In-Reply-To: <51B352C1.8050104@cs.oswego.edu> References: <51B352C1.8050104@cs.oswego.edu> Message-ID: On Sat, Jun 8, 2013 at 8:50 AM, Doug Lea
    wrote: > > But there's nothing about interface Comparable that forces > this to be true. It would be weird but legal if both > are of form, say, "class C implements Comparable". > The antisymmetric property prevents this from being legal. """The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)""" > Which means that you cannot compare them to each other. > From peter.levart at gmail.com Sat Jun 8 20:17:28 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 08 Jun 2013 22:17:28 +0200 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B3059A.4030703@univ-mlv.fr> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> Message-ID: <51B39158.5000003@gmail.com> On 06/08/2013 12:21 PM, Remi Forax wrote: > On 06/07/2013 12:01 PM, Aleksey Shipilev wrote: >> (posting this to hotspot-dev@ and cc-ing core-libs-dev@, as Christian T. >> suggested offline) >> >> Hi guys, > > Hi Aleksey, > >> >> The fix for scalability problem is here: >> http://cr.openjdk.java.net/~shade/7177472/webrev.00/ > > in add, the do/while does something a little weird, if putIfAbsent > returns null, > interned is equals to elem, there is no need to do a e.get() in that > case, > I would prefer a code like this: > > T interned; > do { > expungeStaleElements(); > WeakEntry e = new WeakEntry<>(elem, stale); > WeakEntry exist = map.putIfAbsent(e, e); > interned = (exist == null)? elem: exist.get(); > } while (interned == null); > return interned; Hi Remi, Aleksey, In case the loop retries, there's no need to construct another WeakEntry... T interned; WeakEntry e = new WeakEntry<>(elem, stale); do { expungeStaleElements(); WeakEntry exist = map.putIfAbsent(e, e); interned = (exist == null)? elem: exist.get(); } while (interned == null); return interned; Regards, Peter > > The cast to WeakEntry in expungeStaleElements is not needed. > > In WeakEntry.equals, the null check is not needed because null > instanceof WeakEntry returns false, > and you don't need to cast obj.get() to a WeakEntry given you only > to call equals on entry.get(). > So the code should be: > > > public boolean equals(Object obj) { > if (!(obj instanceof WeakEntry)) { > return false; > } > Object that = ((WeakEntry)obj).get(); > Object mine = get(); > return (that == null || mine == null)? this == obj: > mine.equals(that); > } > > > Otherwise, it looks good. > > R?mi > >> >> Testing: >> - Linux x86_64 builds OK >> - Linux x86_64 java/lang/invoke/ jtreg passes OK >> >> Since this is a proof-of-concept patch at this point, I kept the testing >> minimal. Let me know what other testing you think is needed before the >> integration. >> >> Thanks, >> Aleksey. >> >> *** Rationale and details for the issue follow: *** >> >> This issue was in limbo for an year. The performance issue with >> MethodType.methodType factory leads to abysmal scalability on the >> targeted tests. While this can arguably demonstrated on larger >> workloads, the targeted microbenchmarks are showcasing it nicely. This >> issue was blocking the JSR292 API performance testing, because on large >> enough test server, you will inevitably be bitten by this. >> >> If you run the JMH-enabled [1] microbenchmark: >> http://openjdk.java.net/projects/code-tools/jmh/ >> http://cr.openjdk.java.net/~shade/7177472/jsr292bench.tar.gz >> >> ...on the current jdk8/jdk8, 2x2 i5 2.0 Ghz, Linux x86_64, you will see >> the scalability is going down. ("testCached" makes sure the reference to >> MethodType is always strongly reachable, "testNew" makes sure the >> reference is mostly non-reachable, prompting cache re-fill, "testOOB" >> does not make any precautions about that, and also does not suffer from >> the static overheads entailed by the reference management in first two >> tests). >> >> 1 thread: >> MethodTypeBench.testCached 78 +- 1 nsec/op >> MethodTypeBench.testNew 120 +- 1 nsec/op >> MethodTypeBench.testOOB 41 +- 1 nsec/op >> >> 4 threads: >> MethodTypeBench.testCached 495 +- 40 nsec/op >> MethodTypeBench.testNew 611 +- 37 nsec/op >> MethodTypeBench.testOOB 377 +- 10 nsec/op >> >> In fact, on larger machines it may be as bad as tens/hundreds of >> microseconds to look up the MethodType. With the patch applied, on the >> same 2x2 machine: >> >> 1 thread: >> MethodTypeBench.testCached 92 +- 1 nsec/op >> MethodTypeBench.testNew 101 +- 1 nsec/op >> MethodTypeBench.testOOB 49 +- 1 nsec/op >> >> 4 threads: >> MethodTypeBench.testCached 129 +- 1 nsec/op >> MethodTypeBench.testNew 142 +- 10 nsec/op >> MethodTypeBench.testOOB 89 +- 3 nsec/op >> >> >> ...which means the scalability is back: the average time to look up the >> MethodType is not growing spectacularly when the thread count go up. >> Again, the effect is astonishing on large machines. >> >> Notice that we took some hit in single-threaded performance, and that is >> due to two reasons: a) WeakEntry allocation in get(); b) CHM. With the >> upcoming CHMv8, this starts to look better: >> >> 1 thread: >> MethodTypeBench.testCached 87 +- 1 nsec/op >> MethodTypeBench.testNew 95 +- 1 nsec/op >> MethodTypeBench.testOOB 52 +- 1 nsec/op >> >> 4 threads: >> MethodTypeBench.testCached 121 +- 2 nsec/op >> MethodTypeBench.testNew 141 +- 1 nsec/op >> MethodTypeBench.testOOB 93 +- 5 nsec/op >> >> ...which seems to indicate this change is future-proof. > From iris.clark at oracle.com Mon Jun 10 17:29:11 2013 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 10 Jun 2013 10:29:11 -0700 (PDT) Subject: 8016217: More javadoc warnings In-Reply-To: <51B5AB0A.4010408@oracle.com> References: <51B5AB0A.4010408@oracle.com> Message-ID: Hi, Alan. The changes look good to me. One thing caught my eye. In java.util.Calendar, around lines 2681 and later around 2702 you removed the "
    " --- old/src/share/classes/java/util/Calendar.java 2013-06-10 10:37:52.585879060 +0100 +++ new/src/share/classes/java/util/Calendar.java 2013-06-10 10:37:52.297879063 +0100 @@ -2681,9 +2681,9 @@ * Returns whether this Calendar represents a time * before the time represented by the specified * Object. This method is equivalent to: - * 
    
+     * 
    {@code
      *         compareTo(when) < 0
-     *
    + * } * if and only if when is a Calendar * instance. Otherwise, the method returns false. * But you left them in java.io.Console, javax.security.sasl.SasClient, etc. --- old/src/share/classes/java/io/Console.java 2013-06-10 10:37:17.361879868 +0100 +++ new/src/share/classes/java/io/Console.java 2013-06-10 10:37:17.093879874 +0100 @@ -75,7 +75,7 @@ * manually zero the returned character array after processing to minimize the * lifetime of sensitive data in memory. * - * 
    + * 
    {@code
  * Console cons;
  * char[] passwd;
  * if ((cons = System.console()) != null &&
@@ -83,7 +83,7 @@
  *     ...
  *     java.util.Arrays.fill(passwd, ' ');
  * }
- * 
    
+ * }
    * * @author Xueming Shen * @since 1.6 Was the removal intentional? Thanks, iris -----Original Message----- From: Alan Bateman Sent: Monday, June 10, 2013 3:32 AM To: core-libs-dev Subject: 8016217: More javadoc warnings About 8 months ago I tried an early build of doclint [1] and used it to fix up a bunch issues at the time [2]. It's been awhile, so I decided to try out the latest version to see how it has progressed. All I can say is "Yikes". The good news is that they reported against the original source and that makes it easy when compared to tools that validate the generated html. I decided to fix up a few issues, mostly syntax (escaping of > and < in particular) and a few reference issues that were missed the last time (or are new). There are thousands of other issues for anyone that wants to jump in. I've put the webrev with the changes here: http://cr.openjdk.java.net/~alanb/8016217/webrev/ In total this fixes ~500 issues, although 270 of those were coming from java.sql.DatabaseMetaData due to the number of un-escaped usages of "=>". In many cases, the changes are simply to use {@code ..} or replace with {@code ...}. It is tempting to just do a global replace on existing usages (would fixing up content that is escaped of course). I've run specdiff on the before & after to check that I didn't mess anything up. One obvious difference is that code examples that use generics now have the type parameters going through to the generated javadoc. The webrev touches many areas but as the changes are trivial, I don't need a reviewer from every area. -Alan. [1] http://openjdk.java.net/jeps/172 [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 From Alan.Bateman at oracle.com Mon Jun 10 17:56:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 18:56:29 +0100 Subject: 8016217: More javadoc warnings In-Reply-To: References: <51B5AB0A.4010408@oracle.com> Message-ID: <51B6134D.2010606@oracle.com> On 10/06/2013 18:29, Iris Clark wrote: > Hi, Alan. > > The changes look good to me. > > One thing caught my eye. In java.util.Calendar, around lines 2681 and later around 2702 you removed the "
    " > > --- old/src/share/classes/java/util/Calendar.java 2013-06-10 10:37:52.585879060 +0100 > +++ new/src/share/classes/java/util/Calendar.java 2013-06-10 10:37:52.297879063 +0100 > @@ -2681,9 +2681,9 @@ > * Returns whether thisCalendar represents a time > * before the time represented by the specified > *Object. This method is equivalent to: > - *
    
> +     *
    {@code
>        *         compareTo(when)<  0
> -     *
    > + * } > * if and only ifwhen is aCalendar > * instance. Otherwise, the method returnsfalse. > * > > But you left them in java.io.Console, javax.security.sasl.SasClient, etc. > The
    isn't really needed here (and in several other places). I did experimental with removing a few of them, I guess I just didn't revert these two (but it's completely harmless). Thanks for paying close attention. -Alan From mike.duigou at oracle.com Mon Jun 10 18:04:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Jun 2013 11:04:21 -0700 Subject: 8016217: More javadoc warnings In-Reply-To: <51B5AB0A.4010408@oracle.com> References: <51B5AB0A.4010408@oracle.com> Message-ID: <01ED481A-8A13-48F6-8821-7E6C94834BD2@oracle.com> I took a pass through the patch and nothing leaped out at me either. I wondered about the use of   to prevent an expression from breaking across lines but decided it's OK. On Jun 10 2013, at 03:31 , Alan Bateman wrote: > > About 8 months ago I tried an early build of doclint [1] and used it to fix up a bunch issues at the time [2]. It's been awhile, so I decided to try out the latest version to see how it has progressed. All I can say is "Yikes". The good news is that they reported against the original source and that makes it easy when compared to tools that validate the generated html. > > I decided to fix up a few issues, mostly syntax (escaping of > and < in particular) and a few reference issues that were missed the last time (or are new). There are thousands of other issues for anyone that wants to jump in. > > I've put the webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/8016217/webrev/ > > In total this fixes ~500 issues, although 270 of those were coming from java.sql.DatabaseMetaData due to the number of un-escaped usages of "=>". In many cases, the changes are simply to use {@code ..} or replace with {@code ...}. It is tempting to just do a global replace on existing usages (would fixing up content that is escaped of course). Yes, it's very tempting to do a global pass of: ([^<]*) -> {@code $1} ([^<]*) -> {@code $1} (.*) -> $1 For backporting reasons it would be nice to do this simultaneously for the 7u-dev repo as well. Perhaps at the time of the JDK 9 repo split? With the changes in definitions of i, em, b, strong elements in HTML 5 (http://html5doctor.com/i-b-em-strong-element/) it's no longer important to convert tags to tags. > I've run specdiff on the before & after to check that I didn't mess anything up. One obvious difference is that code examples that use generics now have the type parameters going through to the generated javadoc. > > The webrev touches many areas but as the changes are trivial, I don't need a reviewer from every area. > > -Alan. > > [1] http://openjdk.java.net/jeps/172 > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 From stevenschlansker at gmail.com Mon Jun 10 18:06:14 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 10 Jun 2013 11:06:14 -0700 Subject: Dismal performance of String.intern() Message-ID: Hi core-libs-dev, While doing performance profiling of my application, I discovered that nearly 50% of the time deserializing JSON was spent within String.intern(). I understand that in general interning Strings is not the best approach for things, but I think I have a decent use case -- the value of a certain field is one of a very limited number of valid values (that are not known at compile time, so I cannot use an Enum), and is repeated many millions of times in the JSON stream. I discovered that replacing String.intern() with a ConcurrentHashMap improved performance by almost an order of magnitude. I'm not the only person that discovered this and was surprised: http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern I've been excited about starting to contribute to OpenJDK, so I am thinking that this might be a fun project for me to take on and then contribute back. But I figured I should check in on the list before spending a lot of time tracking this down. I have a couple of preparatory questions: * Has this bottleneck been examined thoroughly before? Am I wishing too hard for performance here? * String.intern() is a native method currently. My understanding is that there is a nontrivial penalty to invoking native methods (at least via JNI, not sure if this is also true for "built ins"?). I assume the reason that this is native is so the Java intern is the same as C++-invoked interns from within the JVM itself. Is this an actual requirement, or could String.intern be replaced with Java code? * If the interning itself must be handled by a symbol table in C++ land as it is today, would a "second level cache" in Java land that invokes a native "intern0" method be acceptable, so that there is a low-penalty "fast path"? If so, this would involve a nonzero memory cost, although I assume that a few thousand references inside of a Map is an OK price to pay for a (for example) 5x speedup. * I assume the String class itself is loaded at a very sensitive time during VM initialization. Having String initialization trigger (for example) ConcurrentHashMap class initialization may cause problems or circularities. If this is the case, would triggering such a load lazily on the first intern() call be "late enough" as to not cause problems? I'm sure that if I get anywhere with this I will have more questions, but this should get me started. Thank you for any advice / insight you may be able to provide! Steven From dan.xu at oracle.com Mon Jun 10 18:06:51 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Mon, 10 Jun 2013 18:06:51 +0000 Subject: hg: jdk8/tl/jdk: 8013827: File.createTempFile hangs with temp file starting with 'com1.4'; ... Message-ID: <20130610180705.468C948102@hg.openjdk.java.net> Changeset: 4a66dd1d7eea Author: dxu Date: 2013-06-10 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a66dd1d7eea 8013827: File.createTempFile hangs with temp file starting with 'com1.4' 8011950: java.io.File.createTempFile enters infinite loop when passed invalid data Reviewed-by: alanb ! src/share/classes/java/io/File.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/CreateNewFile.java ! test/java/io/File/NulFile.java + test/java/io/File/createTempFile/SpecialTempFile.java From martinrb at google.com Sun Jun 9 01:52:40 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 8 Jun 2013 18:52:40 -0700 Subject: Proposal: Comparables.isCommutativelyComparable In-Reply-To: <51B352C1.8050104@cs.oswego.edu> References: <51B352C1.8050104@cs.oswego.edu> Message-ID: On Sat, Jun 8, 2013 at 8:50 AM, Doug Lea
    wrote: > > Suppose you have two objects, x and y, both of the same > type (x.getClass() == y.getClass()) and both known > to be instanceof Comparable. > > Can you compare them? That is, can you safely call > (Comparable)x).compareTo(y); > > > I'm surprised that this hasn't come up for consideration > before. Or maybe I haven't noticed previous discussions? Probably others tried and gave up, because you cannot actually get a reliable answer - you can only get YES NO DUNNO, because some of the generic type information you need may have been erased. My favorite example is: > interface LexicographicList extends Comparable>, List From mike.duigou at oracle.com Mon Jun 10 19:04:47 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Jun 2013 12:04:47 -0700 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B5B46D.8050406@oracle.com> References: <51B5B46D.8050406@oracle.com> Message-ID: StubDelegateImpl.java:: - Could just call Objects.hashCode(ior); RepIdDelegator:: - Could also call Objects.hashCode(delegate) as it extends nothing the super.equals(delegate) is calling Object.equals Mike On Jun 10 2013, at 04:11 , Alan Bateman wrote: > > The warnings from the build of the corba repository on missing hashCode methods have been annoying me for some time. I was hoping they would annoy others too but looks like I blinked first :-) > > Here's the webrev with the changes that I'd like to push to fix the issues: > > http://cr.openjdk.java.net/~alanb/8016218/webrev/ > > Note that there are 3 real issues but they are obvious. I'm running the CORBA tests to make sure that it doesn't break anything. Note that the bulk of the warnings were coming from ParserTable but they turn out not to be interesting because they are only used in the testing framework. > > -Alan. From huizhe.wang at oracle.com Mon Jun 10 19:26:26 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jun 2013 12:26:26 -0700 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: References: <51B38FEC.6090000@oracle.com> Message-ID: <51B62862.1050208@oracle.com> Thanks Lance! As Daniel noted, I added warnings to these additional property settings, but there are a couple of other places in the original JAXP 1.5 impl that did not have warning. I've added the warning message now (in ValidatorHandlerImpl.java and XMLReaderManager.java). Also, in ValidatorHandlerImpl.java, there was a redundant setting at line 677 that would invalidate a 3rd party impl. This was a porting error when the patch was ported from jaxp standalone[1] to JDK. It is now removed. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ [1] jaxp standalone source https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134 Thanks, Joe On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote: > looks fine joe > > -lance > On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: > >> Hi, >> >> This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for the developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >> >> I intend to backport the change to 7u. The change will be identical. >> >> Thanks, >> Joe > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Lance.Andersen at oracle.com Mon Jun 10 19:28:40 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 10 Jun 2013 15:28:40 -0400 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: <51B62862.1050208@oracle.com> References: <51B38FEC.6090000@oracle.com> <51B62862.1050208@oracle.com> Message-ID: looks OK On Jun 10, 2013, at 3:26 PM, huizhe wang wrote: > Thanks Lance! > > As Daniel noted, I added warnings to these additional property settings, but there are a couple of other places in the original JAXP 1.5 impl that did not have warning. I've added the warning message now (in ValidatorHandlerImpl.java and XMLReaderManager.java). Also, in ValidatorHandlerImpl.java, there was a redundant setting at line 677 that would invalidate a 3rd party impl. This was a porting error when the patch was ported from jaxp standalone[1] to JDK. It is now removed. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ > > [1] jaxp standalone source > https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134 > > Thanks, > Joe > > On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote: >> looks fine joe >> >> -lance >> On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: >> >>> Hi, >>> >>> This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for the developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. >>> >>> webrev: >>> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >>> >>> I intend to backport the change to 7u. The change will be identical. >>> >>> Thanks, >>> Joe >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Mon Jun 10 19:59:01 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Jun 2013 21:59:01 +0200 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: References: <51B5B46D.8050406@oracle.com> Message-ID: <51B63005.6070306@oracle.com> On 6/10/13 9:04 PM, Mike Duigou wrote: > StubDelegateImpl.java:: > > - Could just call Objects.hashCode(ior); > > RepIdDelegator:: > > - Could also call Objects.hashCode(delegate) as it extends nothing the super.equals(delegate) is calling Object.equals Depends on whether you intend to backport the patch to jdk7. I suspect that CORBA is like JAXP - in that it needs to be compiled with the bootstrap JDK (if I remember well it's compiled before JAXP). Otherwise - I'd agree with mike :-) -- daniel > > Mike > > On Jun 10 2013, at 04:11 , Alan Bateman wrote: > >> The warnings from the build of the corba repository on missing hashCode methods have been annoying me for some time. I was hoping they would annoy others too but looks like I blinked first :-) >> >> Here's the webrev with the changes that I'd like to push to fix the issues: >> >> http://cr.openjdk.java.net/~alanb/8016218/webrev/ >> >> Note that there are 3 real issues but they are obvious. I'm running the CORBA tests to make sure that it doesn't break anything. Note that the bulk of the warnings were coming from ParserTable but they turn out not to be interesting because they are only used in the testing framework. >> >> -Alan. From huizhe.wang at oracle.com Mon Jun 10 20:00:51 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jun 2013 13:00:51 -0700 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: References: <51B38FEC.6090000@oracle.com> <51B62862.1050208@oracle.com> Message-ID: <51B63073.3020902@oracle.com> Thanks! On 6/10/2013 12:28 PM, Lance Andersen - Oracle wrote: > looks OK > On Jun 10, 2013, at 3:26 PM, huizhe wang wrote: > >> Thanks Lance! >> >> As Daniel noted, I added warnings to these additional property >> settings, but there are a couple of other places in the original JAXP >> 1.5 impl that did not have warning. I've added the warning message >> now (in ValidatorHandlerImpl.java and XMLReaderManager.java). Also, >> in ValidatorHandlerImpl.java, there was a redundant setting at line >> 677 that would invalidate a 3rd party impl. This was a porting error >> when the patch was ported from jaxp standalone[1] to JDK. It is now >> removed. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >> >> [1] jaxp standalone source >> https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134 >> >> Thanks, >> Joe >> >> On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote: >>> looks fine joe >>> >>> -lance >>> On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: >>> >>>> Hi, >>>> >>>> This patch is to continue the support of plugging in 3rd party parser impls (such as Xerces) that do not support JAXP 1.5. The fix is to catch SAXNotRecognizedException, print out a warning, and then continue as usual. The warning is for the developer in case he actually sets the new access* properties on the TransformerFactory but has a 3rd party parser on the classpath that does not support the new properties. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >>>> >>>> I intend to backport the change to 7u. The change will be identical. >>>> >>>> Thanks, >>>> Joe >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >> > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From daniel.fuchs at oracle.com Mon Jun 10 20:04:46 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Jun 2013 22:04:46 +0200 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: <51B62862.1050208@oracle.com> References: <51B38FEC.6090000@oracle.com> <51B62862.1050208@oracle.com> Message-ID: <51B6315E.3010701@oracle.com> Hi Joe, Looks good. I wonder whether using java.util.logging would be more (or less) appropriate than System.err.println()? best regards, -- daniel On 6/10/13 9:26 PM, huizhe wang wrote: > Thanks Lance! > > As Daniel noted, I added warnings to these additional property > settings, but there are a couple of other places in the original JAXP > 1.5 impl that did not have warning. I've added the warning message now > (in ValidatorHandlerImpl.java and XMLReaderManager.java). Also, in > ValidatorHandlerImpl.java, there was a redundant setting at line 677 > that would invalidate a 3rd party impl. This was a porting error when > the patch was ported from jaxp standalone[1] to JDK. It is now removed. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ > > [1] jaxp standalone source > https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134 > > > Thanks, > Joe > > On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote: >> looks fine joe >> >> -lance >> On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: >> >>> Hi, >>> >>> This patch is to continue the support of plugging in 3rd party >>> parser impls (such as Xerces) that do not support JAXP 1.5. The fix >>> is to catch SAXNotRecognizedException, print out a warning, and then >>> continue as usual. The warning is for the developer in case he >>> actually sets the new access* properties on the TransformerFactory >>> but has a 3rd party parser on the classpath that does not support >>> the new properties. >>> >>> webrev: >>> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >>> >>> I intend to backport the change to 7u. The change will be identical. >>> >>> Thanks, >>> Joe >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > From Alan.Bateman at oracle.com Mon Jun 10 20:10:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jun 2013 21:10:55 +0100 Subject: 8016218: Warnings building corba repo due to missing hashCode methods In-Reply-To: <51B63005.6070306@oracle.com> References: <51B5B46D.8050406@oracle.com> <51B63005.6070306@oracle.com> Message-ID: <51B632CF.2080801@oracle.com> On 10/06/2013 20:59, Daniel Fuchs wrote: > On 6/10/13 9:04 PM, Mike Duigou wrote: >> StubDelegateImpl.java:: >> >> - Could just call Objects.hashCode(ior); >> >> RepIdDelegator:: >> >> - Could also call Objects.hashCode(delegate) as it extends nothing >> the super.equals(delegate) is calling Object.equals > Depends on whether you intend to backport the patch to jdk7. > I suspect that CORBA is like JAXP - in that it needs to be compiled > with the > bootstrap JDK (if I remember well it's compiled before JAXP). The corba repository is compiled with the boot JDK so it's not currently possible to use new language features or libraries. Hopefully in time this wart in the build can be sorted out, maybe by compiling it at the same time (there are circularly dependencies due to support for the IIOP transport in a few areas, plus other CORBA interop). So you are right that Objects couldn't be used if back-ported (although I wasn't planning to do that). -Alan. From huizhe.wang at oracle.com Mon Jun 10 20:32:41 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jun 2013 13:32:41 -0700 Subject: RFR (jaxp): 8016153 : Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. In-Reply-To: <51B6315E.3010701@oracle.com> References: <51B38FEC.6090000@oracle.com> <51B62862.1050208@oracle.com> <51B6315E.3010701@oracle.com> Message-ID: <51B637E9.7010908@oracle.com> On 6/10/2013 1:04 PM, Daniel Fuchs wrote: > Hi Joe, > > Looks good. > I wonder whether using java.util.logging would be more (or less) > appropriate than > System.err.println()? It would make sense. The current error/warning report system came from the original source. System.err is consistent with that of the current system. Best, Joe > > best regards, > > -- daniel > > On 6/10/13 9:26 PM, huizhe wang wrote: >> Thanks Lance! >> >> As Daniel noted, I added warnings to these additional property >> settings, but there are a couple of other places in the original JAXP >> 1.5 impl that did not have warning. I've added the warning message >> now (in ValidatorHandlerImpl.java and XMLReaderManager.java). Also, >> in ValidatorHandlerImpl.java, there was a redundant setting at line >> 677 that would invalidate a 3rd party impl. This was a porting error >> when the patch was ported from jaxp standalone[1] to JDK. It is now >> removed. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >> >> [1] jaxp standalone source >> https://java.net/projects/jaxp-sources/sources/svn/content/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java?rev=3134 >> >> >> Thanks, >> Joe >> >> On 6/10/2013 9:44 AM, Lance Andersen - Oracle wrote: >>> looks fine joe >>> >>> -lance >>> On Jun 8, 2013, at 4:11 PM, huizhe wang wrote: >>> >>>> Hi, >>>> >>>> This patch is to continue the support of plugging in 3rd party >>>> parser impls (such as Xerces) that do not support JAXP 1.5. The fix >>>> is to catch SAXNotRecognizedException, print out a warning, and >>>> then continue as usual. The warning is for the developer in case he >>>> actually sets the new access* properties on the TransformerFactory >>>> but has a 3rd party parser on the classpath that does not support >>>> the new properties. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~joehw/jdk8/8016153/webrev/ >>>> >>>> I intend to backport the change to 7u. The change will be identical. >>>> >>>> Thanks, >>>> Joe >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >> > From peter.levart at gmail.com Mon Jun 10 20:57:49 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 10 Jun 2013 22:57:49 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B5F684.9010600@oracle.com> References: <51B5F684.9010600@oracle.com> Message-ID: <51B63DCD.3060702@gmail.com> Hi Aleksey, When 'sun.reflect.noCaches=true' system property is defined, reflectionData() returns null. In that case, the code should cope without using ReflectionData (no caching). See other uses of reflectionData() (for example: in privateGetDeclaredFields())... I should note that ReflectionData is invalidated when the class is redefined. I don't know if generic signature is one of those things that can change with class redefinition, but invalidation is just one purpose of ReflectionData and the other is caching (via SoftReference), so generic signature can be added to it for that purpose. If 'genericSignature' is cached on ReflectionData then it would be consistent to also cache the derived 'genericInfo', what do you think? I don't think 3 fields are needed (genericSignatureResolved, genericSignature & genericInfo). I think one boolean flag (say : genericInfoPresent) and genericInfo is all that is needed. If there was a singleton ClassRepository NONE instance, then event the boolean flag wouldn't be needed. Regards, Peter On 06/10/2013 05:53 PM, Aleksey Shipilev wrote: > Hi, > > This is the follow-up on the issue Doug identified: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html > > I had reworked the patch, webrev is here: > http://cr.openjdk.java.net/~shade/8016236/webrev.01/ > > Notable differences from Doug's version are: > - handle non-generic cases as well > - reuse ReflectionData to cache the interfaces and generic signatures > - code style (chained ternary operators blown up) > - fixes the race along the way > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6398355 > > Testing: > - Linux x86_64/release: build OK > - Linux x86_64/release: java/lang/reflect regression tests OK > - Microbenchmarks show whooping increase in performance, see below > > (If there are no stylistic and other comments, I would like to do the > JPRT submit and/or additional testing [which?]). > > The benchmark is here (you need JMH to build and run): > http://cr.openjdk.java.net/~shade/8016236/classbench.zip > > Before: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 326.835 1.220 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 308.793 2.828 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 312.627 1.637 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 216.983 8.902 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 59.933 0.183 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 65.469 0.284 nsec/op > Doug's version: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 15.106 0.271 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.304 0.024 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.739 0.045 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 213.825 1.346 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 61.651 0.394 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 64.340 0.522 nsec/op > After: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 14.985 0.104 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.874 0.175 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 23.941 0.177 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 8.583 0.044 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 12.400 0.045 nsec/op > Thanks, > Aleksey. From peter.levart at gmail.com Mon Jun 10 21:31:17 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 10 Jun 2013 23:31:17 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B5F684.9010600@oracle.com> References: <51B5F684.9010600@oracle.com> Message-ID: <51B645A5.7000909@gmail.com> Hi Aleksey, While you're at it adding getInterfaces() cache, why not also getSuperclass()? Is it maybe already intrinsified? Regards, Peter On 06/10/2013 05:53 PM, Aleksey Shipilev wrote: > Hi, > > This is the follow-up on the issue Doug identified: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html > > I had reworked the patch, webrev is here: > http://cr.openjdk.java.net/~shade/8016236/webrev.01/ > > Notable differences from Doug's version are: > - handle non-generic cases as well > - reuse ReflectionData to cache the interfaces and generic signatures > - code style (chained ternary operators blown up) > - fixes the race along the way > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6398355 > > Testing: > - Linux x86_64/release: build OK > - Linux x86_64/release: java/lang/reflect regression tests OK > - Microbenchmarks show whooping increase in performance, see below > > (If there are no stylistic and other comments, I would like to do the > JPRT submit and/or additional testing [which?]). > > The benchmark is here (you need JMH to build and run): > http://cr.openjdk.java.net/~shade/8016236/classbench.zip > > Before: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 326.835 1.220 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 308.793 2.828 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 312.627 1.637 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 216.983 8.902 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 59.933 0.183 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 65.469 0.284 nsec/op > Doug's version: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 15.106 0.271 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.304 0.024 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.739 0.045 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 213.825 1.346 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 61.651 0.394 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 64.340 0.522 nsec/op > After: >> Benchmark Mode Thr Cnt Sec Mean Mean error Units >> o.b.ClassBench.generic_getGenericInterfaces avgt 1 5 1 14.985 0.104 nsec/op >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op >> o.b.ClassBench.generic_getTypeParameters avgt 1 5 1 16.874 0.175 nsec/op >> o.b.ClassBench.raw_getGenericInterfaces avgt 1 5 1 23.941 0.177 nsec/op >> o.b.ClassBench.raw_getGenericSuperclass avgt 1 5 1 8.583 0.044 nsec/op >> o.b.ClassBench.raw_getTypeParameters avgt 1 5 1 12.400 0.045 nsec/op > Thanks, > Aleksey. From huizhe.wang at oracle.com Mon Jun 10 21:44:10 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Mon, 10 Jun 2013 21:44:10 +0000 Subject: hg: jdk8/tl/jaxp: 8016153: Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. Message-ID: <20130610214414.774754810C@hg.openjdk.java.net> Changeset: 5c84d4a878f1 Author: joehw Date: 2013-06-10 14:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5c84d4a878f1 8016153: Property http://javax.xml.XMLConstants/property/accessExternalDTD is not recognized. Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java From peter.levart at gmail.com Mon Jun 10 22:18:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Jun 2013 00:18:05 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B63DCD.3060702@gmail.com> References: <51B5F684.9010600@oracle.com> <51B63DCD.3060702@gmail.com> Message-ID: <51B6509D.1010608@gmail.com> On 06/10/2013 10:57 PM, Peter Levart wrote: > I don't think 3 fields are needed (genericSignatureResolved, > genericSignature & genericInfo). I think one boolean flag (say : > genericInfoPresent) and genericInfo is all that is needed. If there > was a singleton ClassRepository NONE instance, then even the boolean > flag wouldn't be needed. Hi Aleksey, Here's what I meant by above (no genericSignature caching is needed and no additional fields): private static class LazyHolder { static final ClassRepository NULL_CLASS_REPOSITORY = ClassRepository.make("Ljava/lang/Object;", null); } // accessor for generic info repository private ClassRepository getGenericInfo() { ClassRepository genericInfo = this.genericInfo; // lazily initialize repository if necessary if (genericInfo == null) { String signature = getGenericSignature(); // create and cache generic info repository this.genericInfo = genericInfo = (signature == null) ? LazyHolder.NULL_CLASS_REPOSITORY : ClassRepository.make(signature, getFactory()); } //return cached repository return genericInfo == LazyHolder.NULL_CLASS_REPOSITORY ? null : genericInfo; } Regards, Peter From christian.thalinger at oracle.com Mon Jun 10 22:52:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 10 Jun 2013 15:52:21 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B5F519.6030307@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> Message-ID: <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> On Jun 10, 2013, at 8:47 AM, Aleksey Shipilev wrote: > On 06/09/2013 12:17 AM, Peter Levart wrote: >> In case the loop retries, there's no need to construct another WeakEntry... >> >> T interned; >> WeakEntry e = new WeakEntry<>(elem, stale); >> do { >> expungeStaleElements(); >> WeakEntry exist = map.putIfAbsent(e, e); >> interned = (exist == null)? elem: exist.get(); >> } while (interned == null); >> return interned; > > That's right, thanks! > > The update is here: > http://cr.openjdk.java.net/~shade/7177472/webrev.02/ > > Testing: > - Linux x86_64 builds OK > - Linux x86_64 java/lang/invoke/ jtreg passes OK > - The microbenchmark scores in the original note are still the same This looks good to me. One thing I mentioned in the bug report is that V8's RegExp shows some MethodType related methods in a -Xprof run: Compiled + native Method 11.9% 2455 + 0 java.util.regex.Pattern$GroupTail.match 11.5% 2382 + 0 java.util.regex.Pattern$Start.match 10.2% 2110 + 0 java.util.regex.Pattern$5.isSatisfiedBy 8.5% 1765 + 0 java.util.regex.Pattern$Branch.match 7.1% 1461 + 0 java.lang.invoke.MethodType$WeakInternSet.get 3.4% 709 + 0 java.util.regex.Pattern$CharProperty.match 2.9% 597 + 1 java.lang.invoke.MethodType.makeImpl Could you run RegExp with Nashorn again with and without your changes? -- Chris > > -Aleksey. > From aph at redhat.com Mon Jun 10 22:55:42 2013 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Jun 2013 23:55:42 +0100 Subject: Dismal performance of String.intern() In-Reply-To: References: Message-ID: <51B6596E.2080701@redhat.com> On 06/10/2013 07:06 PM, Steven Schlansker wrote: > > I discovered that replacing String.intern() with a ConcurrentHashMap > improved performance by almost an order of magnitude. > > I'm not the only person that discovered this and was surprised: > http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern > > I've been excited about starting to contribute to OpenJDK, so I am > thinking that this might be a fun project for me to take on and then > contribute back. But I figured I should check in on the list before > spending a lot of time tracking this down. I have a couple of > preparatory questions: > > * Has this bottleneck been examined thoroughly before? Am I wishing > too hard for performance here? > > * String.intern() is a native method currently. My understanding is > that there is a nontrivial penalty to invoking native methods (at > least via JNI, not sure if this is also true for "built ins"?). That's not really true. For simple JNI methods I've measured the overhead in nanoseconds. > I assume the reason that this is native is so the Java intern is the > same as C++-invoked interns from within the JVM itself. Is this an > actual requirement, or could String.intern be replaced with Java > code? I don't think that replacing intern() with Java code is a great place to begin. Surely your first plan should be to improve the performance of the C++ version. Maybe the only problem is that it needs a better hash table. Rather than get into complex re-engineering of VM startup, this might be an easy fix. Andrew. From stevenschlansker at gmail.com Mon Jun 10 22:59:39 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 10 Jun 2013 15:59:39 -0700 Subject: Dismal performance of String.intern() In-Reply-To: <51B6596E.2080701@redhat.com> References: <51B6596E.2080701@redhat.com> Message-ID: <625EB2BB-8D75-4C74-8D8E-E9FABB445AA1@gmail.com> On Jun 10, 2013, at 3:55 PM, Andrew Haley wrote: > On 06/10/2013 07:06 PM, Steven Schlansker wrote: >> >> I discovered that replacing String.intern() with a ConcurrentHashMap >> improved performance by almost an order of magnitude. >> >> I'm not the only person that discovered this and was surprised: >> http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern >> >> I've been excited about starting to contribute to OpenJDK, so I am >> thinking that this might be a fun project for me to take on and then >> contribute back. But I figured I should check in on the list before >> spending a lot of time tracking this down. I have a couple of >> preparatory questions: >> >> * Has this bottleneck been examined thoroughly before? Am I wishing >> too hard for performance here? >> >> * String.intern() is a native method currently. My understanding is >> that there is a nontrivial penalty to invoking native methods (at >> least via JNI, not sure if this is also true for "built ins"?). > > That's not really true. For simple JNI methods I've measured the > overhead in nanoseconds. > >> I assume the reason that this is native is so the Java intern is the >> same as C++-invoked interns from within the JVM itself. Is this an >> actual requirement, or could String.intern be replaced with Java >> code? > > I don't think that replacing intern() with Java code is a great place > to begin. Surely your first plan should be to improve the performance > of the C++ version. Maybe the only problem is that it needs a better > hash table. Rather than get into complex re-engineering of VM > startup, this might be an easy fix. OK, sounds reasonable. I only mentioned moving it to Java because that's what I know and I already have shown it to be fast enough. I'll see if I can hack the C++ code into faster shape preferentially. From stevenschlansker at gmail.com Mon Jun 10 23:01:28 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 10 Jun 2013 16:01:28 -0700 Subject: Dismal performance of String.intern() In-Reply-To: <51B6596E.2080701@redhat.com> References: <51B6596E.2080701@redhat.com> Message-ID: <8B7ED4DE-7252-4D69-8E90-7BB7ACAF6DB2@gmail.com> On Jun 10, 2013, at 3:55 PM, Andrew Haley wrote: > On 06/10/2013 07:06 PM, Steven Schlansker wrote: >> >> I discovered that replacing String.intern() with a ConcurrentHashMap >> improved performance by almost an order of magnitude. >> >> I'm not the only person that discovered this and was surprised: >> http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern >> >> I've been excited about starting to contribute to OpenJDK, so I am >> thinking that this might be a fun project for me to take on and then >> contribute back. But I figured I should check in on the list before >> spending a lot of time tracking this down. I have a couple of >> preparatory questions: >> >> * Has this bottleneck been examined thoroughly before? Am I wishing >> too hard for performance here? >> >> * String.intern() is a native method currently. My understanding is >> that there is a nontrivial penalty to invoking native methods (at >> least via JNI, not sure if this is also true for "built ins"?). > > That's not really true. For simple JNI methods I've measured the > overhead in nanoseconds. > Sorry to double-reply, but I thought it worthwhile to note that the time to intern strings via ConcurrentHashMap is measured in the low double-digit nanoseconds on my machine, so this may indeed end up being nontrivial. But I will consider it trivial unless I can measure it to be large. >> I assume the reason that this is native is so the Java intern is the >> same as C++-invoked interns from within the JVM itself. Is this an >> actual requirement, or could String.intern be replaced with Java >> code? > > I don't think that replacing intern() with Java code is a great place > to begin. Surely your first plan should be to improve the performance > of the C++ version. Maybe the only problem is that it needs a better > hash table. Rather than get into complex re-engineering of VM > startup, this might be an easy fix. > > Andrew. From mike.duigou at oracle.com Mon Jun 10 23:36:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Jun 2013 16:36:57 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: Message-ID: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> I've done some further updates based upon feedback. I believe this is now "done" and ready for final review. http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/ I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods. Mike On Jun 7 2013, at 10:58 , Mike Duigou wrote: > Hello all; > > I've incorporated feedback from previous rounds and expect to finalize this addition soon. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ > > Any review feedback or suggestions of additional tests welcome. > > Thanks, > > Mike > > From lowasser at google.com Mon Jun 10 23:47:08 2013 From: lowasser at google.com (Louis Wasserman) Date: Mon, 10 Jun 2013 16:47:08 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> References: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> Message-ID: Is there any reason that Collections.unmodifiableSortedSet() shouldn't just delegate to Collections.unmodifiableNavigableSet(), and similarly for the Maps? On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou wrote: > I've done some further updates based upon feedback. I believe this is now > "done" and ready for final review. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/ > > I did find one inconsistency in the implementations SortedSet.headSet and > SortedSet.tailSet methods. > > Mike > > > On Jun 7 2013, at 10:58 , Mike Duigou wrote: > > > Hello all; > > > > I've incorporated feedback from previous rounds and expect to finalize > this addition soon. > > > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ > > > > Any review feedback or suggestions of additional tests welcome. > > > > Thanks, > > > > Mike > > > > > > -- Louis Wasserman From mike.duigou at oracle.com Tue Jun 11 00:32:31 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Jun 2013 17:32:31 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: References: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> Message-ID: <9D273DEC-E680-403E-9FC7-C7D8A088777A@oracle.com> On Jun 10 2013, at 16:47 , Louis Wasserman wrote: > Is there any reason that Collections.unmodifiableSortedSet() shouldn't just delegate to Collections.unmodifiableNavigableSet(), and similarly for the Maps? Some of the implementations are pre-8 and almost certainly have serialized instances sitting on disk somewhere. For the classes not introduced in Java 8 I opted to leave things exactly as they were since we won't ever be able to get rid of the existing impls. Also, if we added a fancy readResolve to EmptyMap that substituted a an EmptyNavigableMap for EmptySortedMap we would have a problem when we tried to serialized that as we would have forgotten what type it originally was and would serialize an EmptyNavigableMap rather than an EmptyMap instance. This couldn't be read by Java 7 or earlier. A clean paper implementation of Collections would only require one Map and one Set implementing the most specialized interface but unfortunately we have to provide serialization compatibility. Mike > On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou wrote: > I've done some further updates based upon feedback. I believe this is now "done" and ready for final review. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/ > > I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods. > > Mike > > > On Jun 7 2013, at 10:58 , Mike Duigou wrote: > > > Hello all; > > > > I've incorporated feedback from previous rounds and expect to finalize this addition soon. > > > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ > > > > Any review feedback or suggestions of additional tests welcome. > > > > Thanks, > > > > Mike > > > > > > > > > -- > Louis Wasserman From mandy.chung at oracle.com Tue Jun 11 02:46:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 10 Jun 2013 19:46:45 -0700 Subject: Review request JDK-8015912: jdeps support to output in dot file format Message-ID: <51B68F95.9060109@oracle.com> This adds jdeps --format=dot option to print the output in dot-style format that can be taken to generate a dependency graph. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file. thanks Mandy From huizhe.wang at oracle.com Tue Jun 11 03:36:29 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 10 Jun 2013 20:36:29 -0700 Subject: RFR (jaxp): 8016133 : Regression: diff. behavior with user-defined SAXParser Message-ID: <51B69B3D.1070707@oracle.com> Hi, This is a quick fix on a regression caused by a previous patch. The XMLReaderFactory uses a class variable (_jarread) to indicate if service file has already been read. Along with this variable, there was another (clsFromJar ) that caches the classname if found in a service file. The 2nd variable and its use were accidentally removed. As a result, the following code would return the 3rd party impl on first call but then fall back to the default impl on subsequent calls because reading service file was skipped when _jarread is true: XMLReader reader = XMLReaderFactory.createXMLReader(); System.out.println("1:" + reader.getClass().getName()); XMLReader reader2 = XMLReaderFactory.createXMLReader(); System.out.println("2:" + reader2.getClass().getName()); The fix is simply recover the original code. Here's the webrev: http://cr.openjdk.java.net/~joehw/jdk8/8016133/webrev/ Thanks, Joe From david.holmes at oracle.com Tue Jun 11 05:43:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2013 15:43:13 +1000 Subject: Dismal performance of String.intern() In-Reply-To: References: Message-ID: <51B6B8F1.5030909@oracle.com> Hi Steven, On 11/06/2013 4:06 AM, Steven Schlansker wrote: > Hi core-libs-dev, > > While doing performance profiling of my application, I discovered that nearly 50% of the time deserializing JSON was spent within String.intern(). I understand that in general interning Strings is not the best approach for things, but I think I have a decent use case -- the value of a certain field is one of a very limited number of valid values (that are not known at compile time, so I cannot use an Enum), and is repeated many millions of times in the JSON stream. > > I discovered that replacing String.intern() with a ConcurrentHashMap improved performance by almost an order of magnitude. > > I'm not the only person that discovered this and was surprised: http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern > > I've been excited about starting to contribute to OpenJDK, so I am thinking that this might be a fun project for me to take on and then contribute back. But I figured I should check in on the list before spending a lot of time tracking this down. I have a couple of preparatory questions: > > * Has this bottleneck been examined thoroughly before? Am I wishing too hard for performance here? > > * String.intern() is a native method currently. My understanding is that there is a nontrivial penalty to invoking native methods (at least via JNI, not sure if this is also true for "built ins"?). I assume the reason that this is native is so the Java intern is the same as C++-invoked interns from within the JVM itself. Is this an actual requirement, or could String.intern be replaced with Java code? As interning is handled inside the VM I've cc'd the hotspot-runtime-dev alias. An important point to note here is that the VM has to intern many Strings itself, hence this is handled in the VM via StringTable::intern. If you moved this to Java then the VM would need to make Java upcalls during classloading etc and that would not be good for performance. David ----- > * If the interning itself must be handled by a symbol table in C++ land as it is today, would a "second level cache" in Java land that invokes a native "intern0" method be acceptable, so that there is a low-penalty "fast path"? If so, this would involve a nonzero memory cost, although I assume that a few thousand references inside of a Map is an OK price to pay for a (for example) 5x speedup. > > * I assume the String class itself is loaded at a very sensitive time during VM initialization. Having String initialization trigger (for example) ConcurrentHashMap class initialization may cause problems or circularities. If this is the case, would triggering such a load lazily on the first intern() call be "late enough" as to not cause problems? > > I'm sure that if I get anywhere with this I will have more questions, but this should get me started. Thank you for any advice / insight you may be able to provide! > > Steven > From david.holmes at oracle.com Tue Jun 11 05:58:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2013 15:58:13 +1000 Subject: Is there a better way to throw this exception? In-Reply-To: <51B19162.9010809@oracle.com> References: <51B0599D.4020906@oracle.com> <51B0A348.70805@gmail.com> <51B19162.9010809@oracle.com> Message-ID: <51B6BC75.6050102@oracle.com> Sorry missed the return after once() in the original code. David On 7/06/2013 5:53 PM, David Holmes wrote: > Peter, > > On 7/06/2013 12:57 AM, Peter Levart wrote: >> On 06/06/2013 11:42 AM, Weijun Wang wrote: >>> Hi All >>> >>> I have a method that could throw two kinds of checked exceptions and >>> possibly other unchecked ones: >>> >>> void once() throws One, Two >>> >>> Now I have a wrapper method that calls once() for multiple times, and >>> want to throw the first exception if *all* fails. Now it looks like >>> >>> void multiple() throws One, Two { >>> Exception saved = null; >>> for (all chances) { >>> try { >>> once(); >>> return; >>> } catch (Exception e) { >>> if (saved != null) saved = e; >>> } >>> } >>> if (saved instanceof One) { >>> throw (One)saved; >>> } else if (saved instanceof One) { >>> throw (Two)saved; >>> } else if (saved instanceof RuntimeException) { >>> throw (RuntimeException)saved; >>> } else { >>> // Not likely, but I've already wrote so many lines. >>> throw new RuntimeException(saved); >>> } >>> } >>> >>> Is there any way I can make it shorter? >> >> Hi Max, >> >> If you don't mind re-throwing the last exception thrown instead of the >> first and you can transform your for loop into a while loop, for example: >> >> void multiple() throws One, Two { >> int tries = 10; >> int i = 0; >> while (true) { >> try { >> once(); >> return; >> } catch (Exception e) { >> if (++i >= tries) { >> throw e; >> } >> } >> } >> } >> >> >> ...otherwise you can re-throw the first exception if you can extract the >> first loop iteration out of the loop: >> >> >> void multiple() throws One, Two { >> try { >> once(); // first chance >> return; >> } catch (Exception e) { >> for (rest of chances) { >> try { >> once(); >> return; >> } >> catch (Exception ignore) {} >> } >> throw e; >> } >> } > > But the first call need not throw. > > David > ----- > > >> >> Regards, Peter >> >>> >>> Thanks >>> Max >> From david.holmes at oracle.com Tue Jun 11 07:08:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Jun 2013 17:08:21 +1000 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently In-Reply-To: <51B5F6BF.6060704@oracle.com> References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com> Message-ID: <51B6CCE5.4050402@oracle.com> On 11/06/2013 1:54 AM, Chris Hegarty wrote: > I'm not sure I ever saw this test fail, but it does look like it has > issues. > > I would much prefer to see a j.u.c.Latch/Phaser used to synchronize > across these threads. I don't think that is possible. The main thread wants to reset the count after the suspend has been issued by "first", but once the suspend has been issued the "first" thread can't signal the synchronizer to let the main thread proceed. The poll around isAlive() does address the main issue of a slowly starting thread. For completeness the count variable should be volatile as well. Cheers, David > -Chris. > > On 10/06/2013 13:51, Ivan Gerasimov wrote: >> Hello everyone! >> >> The test of ThreadGroup.Suspend() was reported to fail on rare occasions. >> It can happen on a busy machine that 1 second delay would not be enough >> for the second thread to start. >> Then the first thread would suspend only itself and the test would fail. >> Earlier, another test was updated for similar reasons [1], [2]. >> >> The proposed test can still report false *positive* results if the >> second thread has had no chance to execute during one second after it >> had started. >> To avoid them there must be a way do distinguish suspended threads. >> >> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ >> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 >> >> >> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 >> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 >> >> Sincerely yours, >> Ivan Gerasimov >> From fweimer at redhat.com Tue Jun 11 07:19:23 2013 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 11 Jun 2013 09:19:23 +0200 Subject: Dismal performance of String.intern() In-Reply-To: <8B7ED4DE-7252-4D69-8E90-7BB7ACAF6DB2@gmail.com> References: <51B6596E.2080701@redhat.com> <8B7ED4DE-7252-4D69-8E90-7BB7ACAF6DB2@gmail.com> Message-ID: <51B6CF7B.6010905@redhat.com> On 06/11/2013 01:01 AM, Steven Schlansker wrote: > Sorry to double-reply, but I thought it worthwhile to note that the time to intern strings via ConcurrentHashMap is measured in the low double-digit nanoseconds on my machine, so this may indeed end up being nontrivial. But I will consider it trivial unless I can measure it to be large. Wouldn't the more suitable comparison be a weak hash map? Interned strings are still subject to garbage collection, after all. -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Tue Jun 11 07:59:15 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 11 Jun 2013 09:59:15 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B60AC6.3030407@oracle.com> References: <51B5F684.9010600@oracle.com> <3FDC74A9-6063-4019-A18F-66AD6F515A0D@oracle.com> <51B60AC6.3030407@oracle.com> Message-ID: <9C2AC39E-3E4F-46B8-AB68-F48C126FA531@oracle.com> On Jun 10, 2013, at 7:20 PM, Aleksey Shipilev wrote: > Thanks for taking a look, Paul! > Can I count your review as official? Unfortunately i am not an unofficial reviewer so can only be counted in the unofficial category for now :-( > > On 06/10/2013 08:44 PM, Paul Sandoz wrote: >>> - reuse ReflectionData to cache the interfaces and generic signatures >> >> Any guess on the size impact due to those new fields in ReflectionData? > > Seems to be additional 16 bytes (boolean+oop+oop+alignment, see below); > again, since the ReflectionData is lazily-constructed, this is not the > issue for most of the classes. > In EE-land a lot more reflection tends to happen on application classes. I see Peter has some ideas to avoid additional fields with a special lazilly initialized ClassRepository instance. Paul. > ---- Before: > > Running 64-bit HotSpot VM. > Using compressed references with 3-bit shift. > Objects are 8 bytes aligned. > > java.lang.Class.ReflectionData > offset size type description > 0 12 (assumed to be the object header) > 12 4 int ReflectionData.redefinedCount > 16 4 Field[] ReflectionData.declaredFields > 20 4 Field[] ReflectionData.publicFields > 24 4 Method[] ReflectionData.declaredMethods > 28 4 Method[] ReflectionData.publicMethods > 32 4 Constructor[] ReflectionData.declaredConstructors > 36 4 Constructor[] ReflectionData.publicConstructors > 40 4 Field[] ReflectionData.declaredPublicFields > 44 4 Method[] ReflectionData.declaredPublicMethods > 48 (object boundary, size estimate) > > ---- After: > > Running 64-bit HotSpot VM. > Using compressed references with 3-bit shift. > Objects are 16 bytes aligned. > > java.lang.Class.ReflectionData > offset size type description > 0 12 (assumed to be the object header) > 12 4 int ReflectionData.redefinedCount > 16 1 boolean ReflectionData.genericSignatureResolved > 17 3 (alignment/padding gap) > 20 4 Field[] ReflectionData.declaredFields > 24 4 Field[] ReflectionData.publicFields > 28 4 Method[] ReflectionData.declaredMethods > 32 4 Method[] ReflectionData.publicMethods > 36 4 Constructor[] ReflectionData.declaredConstructors > 40 4 Constructor[] ReflectionData.publicConstructors > 44 4 Field[] ReflectionData.declaredPublicFields > 48 4 Method[] ReflectionData.declaredPublicMethods > 52 4 Class[] ReflectionData.interfaces > 56 4 String ReflectionData.genericSignature > 60 4 (loss due to the next object alignment) > 64 (object boundary, size estimate) > From sundararajan.athijegannathan at oracle.com Tue Jun 11 08:06:40 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 11 Jun 2013 08:06:40 +0000 Subject: hg: jdk8/tl/nashorn: 7 new changesets Message-ID: <20130611080646.C18524811F@hg.openjdk.java.net> Changeset: bab844827181 Author: sundar Date: 2013-06-06 21:41 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bab844827181 8015346: JSON parsing issues with escaped strings, octal, decimal numbers Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/BlockLexicalContext.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8015346.js Changeset: 918a986b0478 Author: hannesw Date: 2013-06-07 17:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/918a986b0478 8012291: NativeArray is inconsistent in using long for length and index in some places and int for the same in other places Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/examples/array-micro.js + test/script/basic/JDK-8012291.js + test/script/basic/JDK-8012291.js.EXPECTED Changeset: 8f890b6bf6de Author: lagergren Date: 2013-06-10 13:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8f890b6bf6de 8015892: canBeUndefined too conservative for some use before declaration cases Reviewed-by: attila, hannesw ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/ir/Symbol.java + test/script/basic/JDK-8015892.js + test/script/basic/fib_wtf.js + test/script/basic/fib_wtf.js.EXPECTED Changeset: a6f8ea57f048 Author: lagergren Date: 2013-06-10 13:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a6f8ea57f048 8016226: backing out test without third party license approval Reviewed-by: attila, sundar - test/script/basic/fib_wtf.js - test/script/basic/fib_wtf.js.EXPECTED Changeset: 966868ef75ee Author: sundar Date: 2013-06-10 19:54 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/966868ef75ee 8016239: loadWithNewGlobal should support user supplied arguments from the caller Reviewed-by: lagergren, attila, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8016239.js + test/script/basic/JDK-8016239.js.EXPECTED Changeset: 1a5d67424e83 Author: sundar Date: 2013-06-11 13:09 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1a5d67424e83 8015357: a = []; a[0x7fffffff]=1; a.sort()[0] should evaluate to 1 instead of undefined Reviewed-by: hannesw, lagergren + test/script/basic/JDK-8015357.js Changeset: fe830f6daa3f Author: sundar Date: 2013-06-11 13:12 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe830f6daa3f Merge From forax at univ-mlv.fr Tue Jun 11 08:31:27 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Jun 2013 10:31:27 +0200 Subject: Dismal performance of String.intern() In-Reply-To: References: Message-ID: <51B6E05F.9080700@univ-mlv.fr> On 06/10/2013 08:06 PM, Steven Schlansker wrote: > Hi core-libs-dev, Hi Steven, the main issue is that intern() doesn't work in isolation, by example if you write "foo" == new String("foo").intern() the result should be always true so the String cache must be accessible not only from the Java side but also from the VM side. Given that we can do a switch on String since java7, we don't really need to check strings with == in code anymore, I think it's better to change the JSON Parser implementation to use it's own cache (or not) and not rely on String.intern(). cheers, R?mi > > While doing performance profiling of my application, I discovered that nearly 50% of the time deserializing JSON was spent within String.intern(). I understand that in general interning Strings is not the best approach for things, but I think I have a decent use case -- the value of a certain field is one of a very limited number of valid values (that are not known at compile time, so I cannot use an Enum), and is repeated many millions of times in the JSON stream. > > I discovered that replacing String.intern() with a ConcurrentHashMap improved performance by almost an order of magnitude. > > I'm not the only person that discovered this and was surprised: http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern > > I've been excited about starting to contribute to OpenJDK, so I am thinking that this might be a fun project for me to take on and then contribute back. But I figured I should check in on the list before spending a lot of time tracking this down. I have a couple of preparatory questions: > > * Has this bottleneck been examined thoroughly before? Am I wishing too hard for performance here? > > * String.intern() is a native method currently. My understanding is that there is a nontrivial penalty to invoking native methods (at least via JNI, not sure if this is also true for "built ins"?). I assume the reason that this is native is so the Java intern is the same as C++-invoked interns from within the JVM itself. Is this an actual requirement, or could String.intern be replaced with Java code? > > * If the interning itself must be handled by a symbol table in C++ land as it is today, would a "second level cache" in Java land that invokes a native "intern0" method be acceptable, so that there is a low-penalty "fast path"? If so, this would involve a nonzero memory cost, although I assume that a few thousand references inside of a Map is an OK price to pay for a (for example) 5x speedup. > > * I assume the String class itself is loaded at a very sensitive time during VM initialization. Having String initialization trigger (for example) ConcurrentHashMap class initialization may cause problems or circularities. If this is the case, would triggering such a load lazily on the first intern() call be "late enough" as to not cause problems? > > I'm sure that if I get anywhere with this I will have more questions, but this should get me started. Thank you for any advice / insight you may be able to provide! > > Steven > From aleksey.shipilev at oracle.com Tue Jun 11 08:47:06 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 12:47:06 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> Message-ID: <51B6E40A.9050904@oracle.com> On 06/11/2013 02:52 AM, Christian Thalinger wrote: > This looks good to me. Thanks for the review! > Could you run RegExp with Nashorn again with and without your changes? Being single-threaded, the benchmark will not show much of the improvement. Also, the results are rather flaky. Before: 1 thread: 175 +- 5 2 threads: 199 +- 5 msec/op After: 1 thread: 177 +- 6 msec/op 2 threads: 189 +- 6 msec/op -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 08:52:10 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 12:52:10 +0400 Subject: Dismal performance of String.intern() In-Reply-To: <51B6E05F.9080700@univ-mlv.fr> References: <51B6E05F.9080700@univ-mlv.fr> Message-ID: <51B6E53A.4060107@oracle.com> On 06/11/2013 12:31 PM, Remi Forax wrote: > On 06/10/2013 08:06 PM, Steven Schlansker wrote: > Hi Steven, > the main issue is that intern() doesn't work in isolation, > > I think it's better to change the JSON Parser implementation to use it's > own cache (or not) and not rely on String.intern(). +1. IMO, String.intern() is the gateway into VM symbol table, and should be regarded as such. The improvements for String.intern(), if any, then should be on the VM (native) side. Also, I think most people confuse String interning and String de-duplication. Using interning to improve memory footprint is the overkill. Smart deduplicators may carefully balance the overheads of deduplication vs. the memory footprint. -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 09:03:01 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 13:03:01 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B645A5.7000909@gmail.com> References: <51B5F684.9010600@oracle.com> <51B645A5.7000909@gmail.com> Message-ID: <51B6E7C5.8060005@oracle.com> On 06/11/2013 01:31 AM, Peter Levart wrote: > While you're at it adding getInterfaces() cache, why not also > getSuperclass()? Is it maybe already intrinsified? Yes, the C2 code and benchmarking shows it is already an intrinsic. -Aleksey. From vicente.romero at oracle.com Tue Jun 11 08:36:34 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 11 Jun 2013 08:36:34 +0000 Subject: hg: jdk8/tl/langtools: 8008547: javac, warning message: use of ''_'' as an identifier might not be supported in future releases, should be more especific Message-ID: <20130611083640.0978648121@hg.openjdk.java.net> Changeset: bbedff0dc37e Author: vromero Date: 2013-06-11 09:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bbedff0dc37e 8008547: javac, warning message: use of ''_'' as an identifier might not be supported in future releases, should be more especific Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/resources/compiler.properties From vicente.romero at oracle.com Tue Jun 11 09:07:34 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 11 Jun 2013 09:07:34 +0000 Subject: hg: jdk8/tl/langtools: 8007907: javap, method com.sun.tools.javap.Main.run returns 0 even in case of class not found error Message-ID: <20130611090736.E131C48123@hg.openjdk.java.net> Changeset: 7fe655cad9b1 Author: vromero Date: 2013-06-11 09:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7fe655cad9b1 8007907: javap, method com.sun.tools.javap.Main.run returns 0 even in case of class not found error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java ! test/tools/javac/constDebug/ConstDebugTest.java ! test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java + test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java ! test/tools/javap/T4777949.java ! test/tools/javap/T7190862.java From Alan.Bateman at oracle.com Tue Jun 11 09:28:14 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jun 2013 10:28:14 +0100 Subject: Dismal performance of String.intern() In-Reply-To: References: Message-ID: <51B6EDAE.3080300@oracle.com> On 10/06/2013 19:06, Steven Schlansker wrote: > Hi core-libs-dev, > > While doing performance profiling of my application, I discovered that nearly 50% of the time deserializing JSON was spent within String.intern(). I understand that in general interning Strings is not the best approach for things, but I think I have a decent use case -- the value of a certain field is one of a very limited number of valid values (that are not known at compile time, so I cannot use an Enum), and is repeated many millions of times in the JSON stream. > Have you run with -XX:+PrintStringTableStatistics? Might be interesting if you can share the output (it is printed just before the VM terminates). There are also tuning knobs such as StringTableSize and would be interesting to know if you've experimented with. -Alan. From chris.hegarty at oracle.com Tue Jun 11 09:37:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 11 Jun 2013 10:37:45 +0100 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently In-Reply-To: <51B6CCE5.4050402@oracle.com> References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com> <51B6CCE5.4050402@oracle.com> Message-ID: <51B6EFE9.9080104@oracle.com> On 06/11/2013 08:08 AM, David Holmes wrote: > On 11/06/2013 1:54 AM, Chris Hegarty wrote: >> I'm not sure I ever saw this test fail, but it does look like it has >> issues. >> >> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize >> across these threads. > > I don't think that is possible. The main thread wants to reset the count > after the suspend has been issued by "first", but once the suspend has > been issued the "first" thread can't signal the synchronizer to let the > main thread proceed. The poll around isAlive() does address the main > issue of a slowly starting thread. Ah yes, thanks David. In which case I'm fine with the change. > For completeness the count variable should be volatile as well. Agreed. -Chris. > > Cheers, > David > >> -Chris. >> >> On 10/06/2013 13:51, Ivan Gerasimov wrote: >>> Hello everyone! >>> >>> The test of ThreadGroup.Suspend() was reported to fail on rare >>> occasions. >>> It can happen on a busy machine that 1 second delay would not be enough >>> for the second thread to start. >>> Then the first thread would suspend only itself and the test would fail. >>> Earlier, another test was updated for similar reasons [1], [2]. >>> >>> The proposed test can still report false *positive* results if the >>> second thread has had no chance to execute during one second after it >>> had started. >>> To avoid them there must be a way do distinguish suspended threads. >>> >>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ >>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 >>> >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 >>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 >>> >>> Sincerely yours, >>> Ivan Gerasimov >>> From aleksey.shipilev at oracle.com Tue Jun 11 09:56:14 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 13:56:14 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B63DCD.3060702@gmail.com> References: <51B5F684.9010600@oracle.com> <51B63DCD.3060702@gmail.com> Message-ID: <51B6F43E.1070400@oracle.com> Hi Peter, On 06/11/2013 12:57 AM, Peter Levart wrote: > When 'sun.reflect.noCaches=true' system property is defined, > reflectionData() returns null. In that case, the code should cope > without using ReflectionData (no caching). See other uses of > reflectionData() (for example: in privateGetDeclaredFields())... Good catch. Indeed, I was deluged by newReflectionData returning null. Fixed. > If 'genericSignature' is cached on ReflectionData then it would be > consistent to also cache the derived 'genericInfo', what do you > think? "genericSignature" is off the ReflectionData now, so it makes a little sense to move genericInfo there. The interference of genericInfo and class redefinition is an interesting in itself, and I think it should be taken care of elsewhere (notably, when JEP-159 lands). I'm somewhat resistant to do this along with the performance fix. > If there was a singleton ClassRepository NONE instance, then event > the boolean flag wouldn't be needed. Oh, that's a good idea. Implemented. The new webrev is here: http://cr.openjdk.java.net/~shade/8016236/webrev.02/ Testing: - Linux x86_64/release builds OK - Linux x86_64/release jdk/test/java/lang/reflect/ jtreg OK - Microbenchmark scores are still showing the major increase - Layout dumps show Reflection data is 8 bytes more (1 oop + alignment) -Aleksey. From paul.sandoz at oracle.com Tue Jun 11 10:12:44 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 11 Jun 2013 12:12:44 +0200 Subject: RFR 8016308: Updates to j.u.stream.Node/Nodes Message-ID: <6F6B4E32-9FA3-4CD1-914A-E8DBE8C47250@oracle.com> Hi Please review the following patch: http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/ This syncs up java.util.stream.Node/Nodes from the lambda repo to the tl repo. The main changes are related to reducing the code for primitive specializations. There are some temporary functions added to SliceOps.SliceTask, and changes to SliceOps, specifically to improve out of memory issues with infinite or large streams, will follow later on (which incidentally will also use the Node.truncate methods). This patch is based off the following patch that was previously sent out for review: http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/ Paul. From paul.sandoz at oracle.com Tue Jun 11 10:24:18 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 11 Jun 2013 10:24:18 +0000 Subject: hg: jdk8/tl/jdk: 8015895: Int/LongStream.range/rangeClosed; ... Message-ID: <20130611102442.9E0E148127@hg.openjdk.java.net> Changeset: 8d627f324c38 Author: psandoz Date: 2013-06-11 12:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d627f324c38 8015895: Int/LongStream.range/rangeClosed 8012986: Right-bias range spliterators for large ranges Reviewed-by: mduigou ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java ! test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java From peter.levart at gmail.com Tue Jun 11 11:27:39 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 11 Jun 2013 13:27:39 +0200 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B6F43E.1070400@oracle.com> References: <51B5F684.9010600@oracle.com> <51B63DCD.3060702@gmail.com> <51B6F43E.1070400@oracle.com> Message-ID: <51B709AB.6070001@gmail.com> Aleksey, On 06/11/2013 11:56 AM, Aleksey Shipilev wrote: > Hi Peter, > > On 06/11/2013 12:57 AM, Peter Levart wrote: >> When 'sun.reflect.noCaches=true' system property is defined, >> reflectionData() returns null. In that case, the code should cope >> without using ReflectionData (no caching). See other uses of >> reflectionData() (for example: in privateGetDeclaredFields())... > Good catch. Indeed, I was deluged by newReflectionData returning null. > Fixed. > >> If 'genericSignature' is cached on ReflectionData then it would be >> consistent to also cache the derived 'genericInfo', what do you >> think? > "genericSignature" is off the ReflectionData now, so it makes a little > sense to move genericInfo there. The interference of genericInfo and > class redefinition is an interesting in itself, and I think it should be > taken care of elsewhere (notably, when JEP-159 lands). I'm somewhat > resistant to do this along with the performance fix. > >> If there was a singleton ClassRepository NONE instance, then event >> the boolean flag wouldn't be needed. > Oh, that's a good idea. Implemented. > > The new webrev is here: > http://cr.openjdk.java.net/~shade/8016236/webrev.02/ That's good now. I just wonder if renaming of native getGenericSignature -> getGenericSignature0 is still needed now that there's no getGenericSignature non-native method in Class. Every native method ending with '0' has a non-native counterpart with same name (just '0' stripped). Regards, Peter > > Testing: > - Linux x86_64/release builds OK > - Linux x86_64/release jdk/test/java/lang/reflect/ jtreg OK > - Microbenchmark scores are still showing the major increase > - Layout dumps show Reflection data is 8 bytes more (1 oop + alignment) > > -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 11:32:33 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 15:32:33 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B709AB.6070001@gmail.com> References: <51B5F684.9010600@oracle.com> <51B63DCD.3060702@gmail.com> <51B6F43E.1070400@oracle.com> <51B709AB.6070001@gmail.com> Message-ID: <51B70AD1.1050409@oracle.com> On 06/11/2013 03:27 PM, Peter Levart wrote: >> The new webrev is here: >> http://cr.openjdk.java.net/~shade/8016236/webrev.02/ > > That's good now. Thanks! > I just wonder if renaming of native getGenericSignature -> > getGenericSignature0 is still needed now that there's no > getGenericSignature non-native method in Class. Every native method > ending with '0' has a non-native counterpart with same name (just > '0' stripped). I do think that marking the native methods with the suffixes is a good thing, easing the future change in the internal APIs (e.g. introducing non-native getGenericSignature). I can revert this if anybody else thinks otherwise. -Aleksey. From sean.mullan at oracle.com Tue Jun 11 12:08:36 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Jun 2013 08:08:36 -0400 Subject: 8016217: More javadoc warnings In-Reply-To: <51B5AB0A.4010408@oracle.com> References: <51B5AB0A.4010408@oracle.com> Message-ID: <51B71344.8070700@oracle.com> The changes to classes in the security component look fine. One question I have is about the change to javax/xml/crypto/dsig/Manifest.java. Was there a specific error here or did you just want to make this cleaner by removing all of the html special character handling? The reason I ask is that there are many other classes in javax.xml.crypto which have similar javadoc sections, so I am wondering if they have similar issues. Thanks, Sean On 06/10/2013 06:31 AM, Alan Bateman wrote: > > About 8 months ago I tried an early build of doclint [1] and used it to > fix up a bunch issues at the time [2]. It's been awhile, so I decided to > try out the latest version to see how it has progressed. All I can say > is "Yikes". The good news is that they reported against the original > source and that makes it easy when compared to tools that validate the > generated html. > > I decided to fix up a few issues, mostly syntax (escaping of > and < in > particular) and a few reference issues that were missed the last time > (or are new). There are thousands of other issues for anyone that wants > to jump in. > > I've put the webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/8016217/webrev/ > > In total this fixes ~500 issues, although 270 of those were coming from > java.sql.DatabaseMetaData due to the number of un-escaped usages of > "=>". In many cases, the changes are simply to use {@code ..} or replace > with {@code ...}. It is tempting to just do a global replace on > existing usages (would fixing up content that is escaped > of course). > > I've run specdiff on the before & after to check that I didn't mess > anything up. One obvious difference is that code examples that use > generics now have the type parameters going through to the generated > javadoc. > > The webrev touches many areas but as the changes are trivial, I don't > need a reviewer from every area. > > -Alan. > > [1] http://openjdk.java.net/jeps/172 > [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1 From Alan.Bateman at oracle.com Tue Jun 11 12:33:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jun 2013 13:33:43 +0100 Subject: 8016217: More javadoc warnings In-Reply-To: <51B71344.8070700@oracle.com> References: <51B5AB0A.4010408@oracle.com> <51B71344.8070700@oracle.com> Message-ID: <51B71927.10202@oracle.com> On 11/06/2013 13:08, Sean Mullan wrote: > The changes to classes in the security component look fine. One > question I have is about the change to > javax/xml/crypto/dsig/Manifest.java. Was there a specific error here > or did you just want to make this cleaner by removing all of the html > special character handling? The reason I ask is that there are many > other classes in javax.xml.crypto which have similar javadoc sections, > so I am wondering if they have similar issues. The error was at line 41: * <sequence> The > should have been > There are several other examples of the same thing. Also there are several cases (in other areas) where there was an attempt to use < or > but the semicolon was left out. So for this case then I could have fixed it by using > but since this is XML schema definition then I personally think it's a lot more readable to have the original XML in {@code ...}. Another example is the DTD in java/util/Preferences.java where the error was a missing semi-colon, in that case it seems more readable (to me anyway) to have the DTD passed in. Same thing for code examples that have type parameters. As I mentioned in one of the mails yesterday (and I think Mike's mail is agreeing) it is very tempting to replace all usages with {@code ...}. This would require un-doing existing escaping but the result should be more readable and less error-pone when edited. -Alan. From alan.bateman at oracle.com Tue Jun 11 13:15:00 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 11 Jun 2013 13:15:00 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130611131549.2F4AB48132@hg.openjdk.java.net> Changeset: 669be1677ab7 Author: alanb Date: 2013-06-11 11:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/669be1677ab7 7059085: Retire Thread.stop(Throwable) so that it throws UOE Reviewed-by: dholmes, chegar, forax, darcy, mduigou ! src/share/classes/java/lang/Thread.java + test/java/lang/Thread/StopThrowable.java Changeset: 1f33fd081860 Author: alanb Date: 2013-06-11 11:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f33fd081860 8016311: Update j.u.c. tests to avoid using Thread.stop(Throwable) Reviewed-by: alanb Contributed-by: martinrb at google.com ! test/java/util/concurrent/Executors/PrivilegedCallables.java ! test/java/util/concurrent/FutureTask/Throw.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java Changeset: f1a1f65d2861 Author: alanb Date: 2013-06-11 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1a1f65d2861 Merge From Alan.Bateman at oracle.com Tue Jun 11 13:19:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jun 2013 14:19:18 +0100 Subject: Time to put a stop to Thread.stop? In-Reply-To: <51A0A1E8.1000604@oracle.com> References: <5192494F.6040609@oracle.com> <519F68AD.9010505@oracle.com> <51A0A1E8.1000604@oracle.com> Message-ID: <51B723D6.8060509@oracle.com> On 25/05/2013 12:35, Alan Bateman wrote: > On 24/05/2013 19:14, Martin Buchholz wrote: >> : >> >> Alan, you're telling everyone there's no need for Thread.stop, but >> you are replacing usages in tests with calls to Unsafe, which is not >> available to normal code. So you have a kind of moral obligation >> here to replace usages with "ordinary" java code. There are other >> ways to do sneakyThrow, and perhaps a sneakyRethrow method should be >> added to the jdk test library. > For these the tests then it shouldn't really matter but if you or Doug > would prefer if they are changed to use sneakyThrow then we can do that. Martin has pushed updates to the 4 tests to the jsr166 CVS so I'll going to push these to jdk8/tl forest along with the Thread.stop changes. -Alan From paul.sandoz at oracle.com Tue Jun 11 13:23:33 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 11 Jun 2013 15:23:33 +0200 Subject: RFR 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink Message-ID: Hi, Please review the following patch contributed by Brian Goetz: http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/ This syncs most of code in the pipeline implementations from lambda to tl (the remaining aspects are to do with Comparator changes which will follow later). This patch fixes a bug for the filter and flatMap operations, where the corresponding Sink implementations that were incorrectly reporting size to downstream Sinks. A filter or flatMap might result in the output stream containing a different number of elements to that of the input stream so we have to say to a downstream sink "I don't know what my size will be". Paul. From ivan.gerasimov at oracle.com Tue Jun 11 14:13:36 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 11 Jun 2013 18:13:36 +0400 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently In-Reply-To: <51B6EFE9.9080104@oracle.com> References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com> <51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com> Message-ID: <51B73090.5010407@oracle.com> Chris and David, thanks for review. I've updated the test so the threads use CountDownLatch to wait for each other. Now, instead of checking whether the 'second' thread has incremented a count, the 'main' thread waits for it to call countDown(). If a timeout was elapsed before the call, I assume that the 'second' thread is suspended and the test passes. Could you please review the updated webrev: http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/ Sincerely, Ivan On 11.06.2013 13:37, Chris Hegarty wrote: > On 06/11/2013 08:08 AM, David Holmes wrote: >> On 11/06/2013 1:54 AM, Chris Hegarty wrote: >>> I'm not sure I ever saw this test fail, but it does look like it has >>> issues. >>> >>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize >>> across these threads. >> >> I don't think that is possible. The main thread wants to reset the count >> after the suspend has been issued by "first", but once the suspend has >> been issued the "first" thread can't signal the synchronizer to let the >> main thread proceed. The poll around isAlive() does address the main >> issue of a slowly starting thread. > > Ah yes, thanks David. In which case I'm fine with the change. > >> For completeness the count variable should be volatile as well. > > Agreed. > > -Chris. > >> >> Cheers, >> David >> >>> -Chris. >>> >>> On 10/06/2013 13:51, Ivan Gerasimov wrote: >>>> Hello everyone! >>>> >>>> The test of ThreadGroup.Suspend() was reported to fail on rare >>>> occasions. >>>> It can happen on a busy machine that 1 second delay would not be >>>> enough >>>> for the second thread to start. >>>> Then the first thread would suspend only itself and the test would >>>> fail. >>>> Earlier, another test was updated for similar reasons [1], [2]. >>>> >>>> The proposed test can still report false *positive* results if the >>>> second thread has had no chance to execute during one second after it >>>> had started. >>>> To avoid them there must be a way do distinguish suspended threads. >>>> >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ >>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 >>>> >>>> >>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 >>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 >>>> >>>> Sincerely yours, >>>> Ivan Gerasimov >>>> > > From christian.thalinger at oracle.com Tue Jun 11 15:43:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 08:43:02 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B6E40A.9050904@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> Message-ID: <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> On Jun 11, 2013, at 1:47 AM, Aleksey Shipilev wrote: > On 06/11/2013 02:52 AM, Christian Thalinger wrote: >> This looks good to me. > > Thanks for the review! > >> Could you run RegExp with Nashorn again with and without your changes? > > Being single-threaded, the benchmark will not show much of the > improvement. Also, the results are rather flaky. > > Before: > 1 thread: 175 +- 5 > 2 threads: 199 +- 5 msec/op > > After: > 1 thread: 177 +- 6 msec/op > 2 threads: 189 +- 6 msec/op Thanks for this but I was thinking running it with -Xprof to see whether some of the table methods show up on the profile. -- Chris > > -Aleksey. From david.r.chase at oracle.com Tue Jun 11 15:58:41 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 11 Jun 2013 11:58:41 -0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <51B5F684.9010600@oracle.com> References: <51B5F684.9010600@oracle.com> Message-ID: <5DBC34FA-D036-4B46-9AA3-21F9216FB86E@oracle.com> On 2013-06-10, at 11:53 AM, Aleksey Shipilev wrote: >> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op Am I reading this correctly? 0.008 nsec/op means 125 times 10-to-the-9th ops per second. That's a high clock rate. Have most been optimized out, are we using parallelism to our advantage, what happened here? David From aleksey.shipilev at oracle.com Tue Jun 11 16:01:53 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 20:01:53 +0400 Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance improvement In-Reply-To: <5DBC34FA-D036-4B46-9AA3-21F9216FB86E@oracle.com> References: <51B5F684.9010600@oracle.com> <5DBC34FA-D036-4B46-9AA3-21F9216FB86E@oracle.com> Message-ID: <51B749F1.5010002@oracle.com> On 06/11/2013 07:58 PM, David Chase wrote: > > On 2013-06-10, at 11:53 AM, Aleksey Shipilev wrote: > >>> o.b.ClassBench.generic_getGenericSuperclass avgt 1 5 1 5.300 0.008 nsec/op > > Am I reading this correctly? 0.008 nsec/op means 125 times 10-to-the-9th ops per second. Look up to the table header: that is the error margin. The result is 5.300 +- 0.008 nsec/op. > That's a high clock rate. Yeah, that is why any benchmark rating lower than 1 ns/op is raising the red flag all over the performance guys. :) -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 16:03:02 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 20:03:02 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> Message-ID: <51B74A36.8010802@oracle.com> On 06/11/2013 07:43 PM, Christian Thalinger wrote: > Thanks for this but I was thinking running it with -Xprof to see > whether some of the table methods show up on the profile. I put little trust into this kind of profiling, but here's the sample output from JMH -prof stack, while running with 4 threads: Before: > Iteration 5 (20s in 4 threads): 380.982 msec/op > Stack | 24.8% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt > | 6.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search > | 5.2% RUNNABLE java.lang.Class.getClassLoader0 > | 3.3% RUNNABLE java.lang.ThreadLocal.get > | 3.0% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. > | 2.9% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace > | 2.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange > | 2.3% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec > | 2.1% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.groups > | 1.9% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace > | 45.6% (other) > | After: > Iteration 5 (20s in 4 threads): 358.121 msec/op > Stack | 24.7% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt > | 5.7% RUNNABLE java.lang.Class.getClassLoader0 > | 5.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search > | 3.5% RUNNABLE java.lang.ThreadLocal.get > | 3.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. > | 2.7% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace > | 2.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange > | 1.8% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec > | 1.7% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace > | 1.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.StackMachine.pop > | 47.3% (other) > | -Xprof shows the similar data. -Aleksey. From christian.thalinger at oracle.com Tue Jun 11 16:06:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 09:06:13 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B74A36.8010802@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> Message-ID: <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> On Jun 11, 2013, at 9:03 AM, Aleksey Shipilev wrote: > On 06/11/2013 07:43 PM, Christian Thalinger wrote: >> Thanks for this but I was thinking running it with -Xprof to see >> whether some of the table methods show up on the profile. > > I put little trust into this kind of profiling, but here's the sample > output from JMH -prof stack, while running with 4 threads: > > Before: >> Iteration 5 (20s in 4 threads): 380.982 msec/op >> Stack | 24.8% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt >> | 6.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search >> | 5.2% RUNNABLE java.lang.Class.getClassLoader0 >> | 3.3% RUNNABLE java.lang.ThreadLocal.get >> | 3.0% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. >> | 2.9% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace >> | 2.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange >> | 2.3% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec >> | 2.1% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.groups >> | 1.9% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace >> | 45.6% (other) >> | > > > After: >> Iteration 5 (20s in 4 threads): 358.121 msec/op >> Stack | 24.7% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.ByteCodeMachine.matchAt >> | 5.7% RUNNABLE java.lang.Class.getClassLoader0 >> | 5.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.SearchAlgorithm$3.search >> | 3.5% RUNNABLE java.lang.ThreadLocal.get >> | 3.4% RUNNABLE jdk.nashorn.internal.runtime.regexp.JoniRegExp$JoniMatcher. >> | 2.7% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.replace >> | 2.3% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.Matcher.forwardSearchRange >> | 1.8% RUNNABLE jdk.nashorn.internal.objects.NativeRegExp.exec >> | 1.7% RUNNABLE jdk.nashorn.internal.objects.NativeString.replace >> | 1.5% RUNNABLE jdk.nashorn.internal.runtime.regexp.joni.StackMachine.pop >> | 47.3% (other) >> | > > -Xprof shows the similar data. Odd. It showed up for me last time. Maybe it's related to using Joni now. Anyway, let's push this. -- Chris > > -Aleksey. From aleksey.shipilev at oracle.com Tue Jun 11 16:08:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Jun 2013 20:08:27 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> Message-ID: <51B74B7B.7010104@oracle.com> On 06/11/2013 08:06 PM, Christian Thalinger wrote: > Anyway, let's push this. Do you want me any other testing done? vm.mlvm.testlist is OK, but I haven't done the full JPRT test cycle, only the build one. -Aleksey. From joe.darcy at oracle.com Tue Jun 11 16:34:03 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 11 Jun 2013 09:34:03 -0700 Subject: 8016217: More javadoc warnings In-Reply-To: <51B71927.10202@oracle.com> References: <51B5AB0A.4010408@oracle.com> <51B71344.8070700@oracle.com> <51B71927.10202@oracle.com> Message-ID: <51B7517B.1080306@oracle.com> On 6/11/2013 5:33 AM, Alan Bateman wrote: > On 11/06/2013 13:08, Sean Mullan wrote: >> The changes to classes in the security component look fine. One >> question I have is about the change to >> javax/xml/crypto/dsig/Manifest.java. Was there a specific error here >> or did you just want to make this cleaner by removing all of the html >> special character handling? The reason I ask is that there are many >> other classes in javax.xml.crypto which have similar javadoc >> sections, so I am wondering if they have similar issues. > The error was at line 41: > > * <sequence> > > The > should have been > > > There are several other examples of the same thing. Also there are > several cases (in other areas) where there was an attempt to use < > or > but the semicolon was left out. > > So for this case then I could have fixed it by using > but since > this is XML schema definition then I personally think it's a lot more > readable to have the original XML in {@code ...}. Another example is > the DTD in java/util/Preferences.java where the error was a missing > semi-colon, in that case it seems more readable (to me anyway) to have > the DTD passed in. Same thing for code examples that have type > parameters. As I mentioned in one of the mails yesterday (and I think > Mike's mail is agreeing) it is very tempting to replace all > usages with {@code ...}. This would require un-doing > existing escaping but the result should be more readable and less > error-pone when edited. I would support (and even help review!) a bulk change of foo to {@code foo}. Whenever I look at foo, my eyes hurt. IIRC, there are a few cases which require HTML escaping, like trying to output a fixed-width "@" character, but they are a very small minority. -Joe From forax at univ-mlv.fr Tue Jun 11 16:59:55 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Jun 2013 18:59:55 +0200 Subject: forEach on HashMap and IdentityHashMap Message-ID: <51B7578B.7010506@univ-mlv.fr> Hi guys, This mail was originality sent to lambda-lib EG but Brian ask me to also send it here to not forget. We should provide an implementation of forEach for HashMap that avoid to create an Iterator, HashMap is too common to not have it's dedicated implementation (ArrayList by example has its own implementation of forEach). There is also another implementation that should have a specific implementation IdentityHashMap because entrySet() creates map entries on the fly so having a specific implementation that will not allocatin entries will improve performance (a lot for big identity hashmap). cheers, R?mi From martinrb at google.com Tue Jun 11 17:11:34 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Jun 2013 10:11:34 -0700 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <51B7578B.7010506@univ-mlv.fr> References: <51B7578B.7010506@univ-mlv.fr> Message-ID: I'm not an expert on the new-fangled lambda lib stuff, but ... I totally agree with your reasoning. These core classes should be as efficient as we can make them. On Tue, Jun 11, 2013 at 9:59 AM, Remi Forax wrote: > Hi guys, > This mail was originality sent to lambda-lib EG but Brian ask me to also > send it here to not forget. > > We should provide an implementation of forEach for HashMap that avoid to > create an Iterator, > HashMap is too common to not have it's dedicated implementation > (ArrayList by example has its own implementation of forEach). > > There is also another implementation that should have a specific > implementation IdentityHashMap because > entrySet() creates map entries on the fly so having a specific > implementation that will not allocatin entries will improve performance > (a lot for big identity hashmap). > > cheers, > R?mi > From naoto.sato at oracle.com Tue Jun 11 18:19:40 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 11 Jun 2013 18:19:40 +0000 Subject: hg: jdk8/tl/jdk: 8015960: java/util/Locale/LocaleProviders.java failing again on Windows Message-ID: <20130611181957.EF39148143@hg.openjdk.java.net> Changeset: cadb0ef6e931 Author: naoto Date: 2013-06-11 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cadb0ef6e931 8015960: java/util/Locale/LocaleProviders.java failing again on Windows Reviewed-by: alanb ! test/java/util/Locale/LocaleProviders.java From christian.thalinger at oracle.com Tue Jun 11 18:24:48 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 11:24:48 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B74B7B.7010104@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> Message-ID: <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: > On 06/11/2013 08:06 PM, Christian Thalinger wrote: >> Anyway, let's push this. > > Do you want me any other testing done? vm.mlvm.testlist is OK, but I > haven't done the full JPRT test cycle, only the build one. You could do a full Nashorn 262 run. That would shake out bugs. -- Chris > > -Aleksey. From martinrb at google.com Tue Jun 11 19:23:48 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 11 Jun 2013 12:23:48 -0700 Subject: 8016217: More javadoc warnings In-Reply-To: <51B7517B.1080306@oracle.com> References: <51B5AB0A.4010408@oracle.com> <51B71344.8070700@oracle.com> <51B71927.10202@oracle.com> <51B7517B.1080306@oracle.com> Message-ID: On Tue, Jun 11, 2013 at 9:34 AM, Joe Darcy wrote: > > I would support (and even help review!) a bulk change of foo > to {@code foo}. Whenever I look at foo, my eyes hurt. IIRC, > there are a few cases which require HTML escaping, like trying to output a > fixed-width "@" character, but they are a very small minority. jsr166 CVS has been converted in this manner, and only a few stragglers remain. I support jdk-wide coding style updates like this. From brent.christian at oracle.com Tue Jun 11 20:32:42 2013 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 11 Jun 2013 13:32:42 -0700 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String Message-ID: <51B7896A.70109@oracle.com> Hi, Please review my fix for 8010325. Some background: The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value. Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used. By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed. The webrev is here: http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ Thanks, -Brent 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e 2. http://bugs.sun.com/view_bug.do?bug_id=8005698 3. http://bugs.sun.com/view_bug.do?bug_id=8005704 From henry.jen at oracle.com Tue Jun 11 21:04:38 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 11 Jun 2013 14:04:38 -0700 Subject: RFR 8009736: Comparator API cleanup Message-ID: <51B790E6.6020209@oracle.com> Hi, Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/ Highlight of changes, - Comparators class is now only package-private implementations. The public static methods have been move to other arguably more appropriate places, mostly in Comparator. - Comparator.reverseOrder() is renamed to Comparator.reversed() - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to wrap up a comparator to be null-friendly. To see the API changes, found the specdiff at http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html Cheers, Henry From mike.duigou at oracle.com Tue Jun 11 21:06:33 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Jun 2013 14:06:33 -0700 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <51B7578B.7010506@univ-mlv.fr> References: <51B7578B.7010506@univ-mlv.fr> Message-ID: <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> On Jun 11 2013, at 09:59 , Remi Forax wrote: > Hi guys, > This mail was originality sent to lambda-lib EG but Brian ask me to also send it here to not forget. > > We should provide an implementation of forEach for HashMap that avoid to create an Iterator, > HashMap is too common to not have it's dedicated implementation I assume you mean the forEach on the entrySet. > (ArrayList by example has its own implementation of forEach). > > There is also another implementation that should have a specific implementation IdentityHashMap because > entrySet() creates map entries on the fly so having a specific implementation that will not allocatin entries will improve performance > (a lot for big identity hashmap). Are you suggesting adding a IdentityMap.forEach(BiConsumer) or re-using the Map.Entry passed to the consumer in entrySet().forEach(Consumer)? Mike > cheers, > R?mi From aleksey.shipilev at oracle.com Tue Jun 11 21:21:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 12 Jun 2013 01:21:45 +0400 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> Message-ID: <51B794E9.2040405@oracle.com> On 06/11/2013 10:24 PM, Christian Thalinger wrote: > > On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: > >> On 06/11/2013 08:06 PM, Christian Thalinger wrote: >>> Anyway, let's push this. >> >> Do you want me any other testing done? vm.mlvm.testlist is OK, but I >> haven't done the full JPRT test cycle, only the build one. > > You could do a full Nashorn 262 run. That would shake out bugs. Done. Linux x86_64/release passes test262parallel with either clean or patched build. -Aleksey. From brian.burkhalter at oracle.com Tue Jun 11 21:31:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 11 Jun 2013 14:31:31 -0700 (PDT) Subject: Status update: BigInteger performance enhancements Message-ID: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> We previously identified four phases of BigInteger performance improvement based on contributions from Alan Eliasen and Tim Buktu: 1) Multiplication and exponentiation - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 2) Conversion to string - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 3) Division - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 4) Multiplication and division of very large integers - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 The current status by phase is as follows: 1) 4837946 and 4646474 * Code reviewed by me and posted for public review - http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html. * Correctness verification partially complete. * Preliminary micro-benchmarking on development laptop. 2) 4641897 * Code reviewed by me but not yet posted. * Rudimentary micro-benchmarking on development laptop. 3) 8014319 No progress. 4) 8014320 No progress. On my development laptop, micro-benchmarking suggested that the values of the multiplication, squaring, and radix conversion algorithm crossover thresholds for phases 1 and 2 are significantly lower than they should be. On other, newer systems, the values appeared to be fairly close to appropriate values. The current plan is in effect first to identify reasonable values for these thresholds which do not exhibit performance regressions on the matrix of platforms of interest. The idea has also surfaced to define system properties by means of which the thresholds could be set by applications. Given the availability of such properties, the threshold values estimated by micro-benchmarking would be the default values if no system property were specified for the threshold of interest. Work on threshold evaluation and the review and validation testing of phase 3 will continue in parallel with other work, some of which will likely affect the same code in which case the changes will be merged. Brian From brian.burkhalter at oracle.com Tue Jun 11 22:47:31 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 11 Jun 2013 15:47:31 -0700 Subject: RFR 7192954+4396272: Fix Float.parseFloat to round correctly and preserve monotonicity Message-ID: This contributed patch http://cr.openjdk.java.net/~bpb/4396272%2b7192954/ fixes these two issues: 1) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192954 - Fix Float.parseFloat to round correctly and preserve monotonicity 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272 - Parsing double fails to follow IEEE for largest decimal the should yield 0 For 7192954, "stickyRound()" is replaced by actual code development containing a correction loop in floatValue() analogous to that in doubleValue(). For 4396272, when the difference between the scaled big-int versions of the exact value and the candidate double value is exactly 1/2*ULP, and the candidate value <= 2*Double.MIN_NORMAL, then form the correction statement in a way that avoids rounding the intermediate result to zero thereby preventing correction. For reference see also this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014788.html Thanks, Brian From lowasser at google.com Tue Jun 11 23:04:38 2013 From: lowasser at google.com (Louis Wasserman) Date: Tue, 11 Jun 2013 16:04:38 -0700 Subject: Status update: BigInteger performance enhancements In-Reply-To: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> References: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> Message-ID: Any update on http://bugs.sun.com/view_bug.do?bug_id=7131192 ? On Tue, Jun 11, 2013 at 2:31 PM, Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > We previously identified four phases of BigInteger performance improvement > based on contributions from Alan Eliasen and Tim Buktu: > > 1) Multiplication and exponentiation - > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 and > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474 > 2) Conversion to string - > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897 > 3) Division - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014319 > 4) Multiplication and division of very large integers - > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014320 > > The current status by phase is as follows: > > 1) 4837946 and 4646474 > * Code reviewed by me and posted for public review - > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html. > * Correctness verification partially complete. > * Preliminary micro-benchmarking on development laptop. > > 2) 4641897 > * Code reviewed by me but not yet posted. > * Rudimentary micro-benchmarking on development laptop. > > 3) 8014319 > No progress. > > 4) 8014320 > No progress. > > On my development laptop, micro-benchmarking suggested that the values of > the multiplication, squaring, and radix conversion algorithm crossover > thresholds for phases 1 and 2 are significantly lower than they should be. > On other, newer systems, the values appeared to be fairly close to > appropriate values. > > The current plan is in effect first to identify reasonable values for > these thresholds which do not exhibit performance regressions on the matrix > of platforms of interest. The idea has also surfaced to define system > properties by means of which the thresholds could be set by applications. > Given the availability of such properties, the threshold values estimated > by micro-benchmarking would be the default values if no system property > were specified for the threshold of interest. > > Work on threshold evaluation and the review and validation testing of > phase 3 will continue in parallel with other work, some of which will > likely affect the same code in which case the changes will be merged. > > Brian -- Louis Wasserman From brian.burkhalter at oracle.com Tue Jun 11 23:08:05 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 11 Jun 2013 16:08:05 -0700 Subject: Status update: BigInteger performance enhancements In-Reply-To: References: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> Message-ID: <1CD2A414-3E97-4C85-A949-521CEAD262B4@oracle.com> Yes. I was just looking at it again today. I was planning to post its RFR after the one I just posted for 7192954+4396272 has been cleared. The changes for 7131192 are disjoint with the other BigInteger performance improvements in the queue so this should be able to be patched in easily. Brian On Jun 11, 2013, at 4:04 PM, Louis Wasserman wrote: > Any update on http://bugs.sun.com/view_bug.do?bug_id=7131192 ? From mike.duigou at oracle.com Tue Jun 11 22:39:51 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 11 Jun 2013 22:39:51 +0000 Subject: hg: jdk8/tl/jdk: 8016213: Convert j2se NetBeans project to use top-level make targets Message-ID: <20130611224018.2CE5448153@hg.openjdk.java.net> Changeset: 7f697d028937 Author: mduigou Date: 2013-06-11 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f697d028937 8016213: Convert j2se NetBeans project to use top-level make targets Reviewed-by: chegar ! make/netbeans/common/shared.xml ! make/netbeans/j2se/build.xml From christian.thalinger at oracle.com Wed Jun 12 02:16:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 11 Jun 2013 19:16:06 -0700 Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability In-Reply-To: <51B794E9.2040405@oracle.com> References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr> <51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com> <88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com> <51B6E40A.9050904@oracle.com> <30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com> <51B74A36.8010802@oracle.com> <53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com> <51B74B7B.7010104@oracle.com> <3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com> <51B794E9.2040405@oracle.com> Message-ID: On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev wrote: > On 06/11/2013 10:24 PM, Christian Thalinger wrote: >> >> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev wrote: >> >>> On 06/11/2013 08:06 PM, Christian Thalinger wrote: >>>> Anyway, let's push this. >>> >>> Do you want me any other testing done? vm.mlvm.testlist is OK, but I >>> haven't done the full JPRT test cycle, only the build one. >> >> You could do a full Nashorn 262 run. That would shake out bugs. > > Done. Linux x86_64/release passes test262parallel with either clean or > patched build. Thanks for verifying. I'll push your change tomorrow. -- Chris > > -Aleksey. > From alan.bateman at oracle.com Wed Jun 12 07:07:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 12 Jun 2013 07:07:50 +0000 Subject: hg: jdk8/tl/jdk: 8016370: javadoc warnings, unexpected

    mostly Message-ID: <20130612070811.2BF6E4816C@hg.openjdk.java.net> Changeset: f56b5c243f7c Author: alanb Date: 2013-06-12 08:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f56b5c243f7c 8016370: javadoc warnings, unexpected

    mostly Reviewed-by: martin, jjg ! makefiles/scripts/genExceptions.sh ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteOrder.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/Channel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/Pipe.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/SelectionKey.java ! src/share/classes/java/nio/channels/Selector.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectionKey.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/CoderResult.java ! src/share/classes/java/nio/charset/CodingErrorAction.java ! src/share/classes/java/nio/charset/UnmappableCharacterException.java ! src/share/classes/java/nio/charset/spi/CharsetProvider.java From peter.levart at gmail.com Wed Jun 12 07:45:44 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Jun 2013 09:45:44 +0200 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> References: <51B7578B.7010506@univ-mlv.fr> <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> Message-ID: <51B82728.5050703@gmail.com> On 06/11/2013 11:06 PM, Mike Duigou wrote: > On Jun 11 2013, at 09:59 , Remi Forax wrote: > >> Hi guys, >> This mail was originality sent to lambda-lib EG but Brian ask me to also send it here to not forget. >> >> We should provide an implementation of forEach for HashMap that avoid to create an Iterator, >> HashMap is too common to not have it's dedicated implementation > I assume you mean the forEach on the entrySet. > >> (ArrayList by example has its own implementation of forEach). >> >> There is also another implementation that should have a specific implementation IdentityHashMap because >> entrySet() creates map entries on the fly so having a specific implementation that will not allocatin entries will improve performance >> (a lot for big identity hashmap). > Are you suggesting adding a IdentityMap.forEach(BiConsumer) or re-using the Map.Entry passed to the consumer in entrySet().forEach(Consumer)? That's a very good idea. Why not adding the following default method to Map interface: default void forEach(BiConsumer sink) { for (Map.Entry entry : entrySet()) { sink.apply(entry.getKey(), entry.getValue()); } } ...and override it in IHM, HM/LHM, CHM with optimal implementations... Regards, Peter > > Mike > >> cheers, >> R?mi From paul.sandoz at oracle.com Wed Jun 12 08:20:04 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 10:20:04 +0200 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <51B82728.5050703@gmail.com> References: <51B7578B.7010506@univ-mlv.fr> <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> <51B82728.5050703@gmail.com> Message-ID: On Jun 12, 2013, at 9:45 AM, Peter Levart wrote: > On 06/11/2013 11:06 PM, Mike Duigou wrote: >> On Jun 11 2013, at 09:59 , Remi Forax wrote: >> >>> Hi guys, >>> This mail was originality sent to lambda-lib EG but Brian ask me to also send it here to not forget. >>> >>> We should provide an implementation of forEach for HashMap that avoid to create an Iterator, >>> HashMap is too common to not have it's dedicated implementation >> I assume you mean the forEach on the entrySet. >> >>> (ArrayList by example has its own implementation of forEach). >>> >>> There is also another implementation that should have a specific implementation IdentityHashMap because >>> entrySet() creates map entries on the fly so having a specific implementation that will not allocatin entries will improve performance >>> (a lot for big identity hashmap). >> Are you suggesting adding a IdentityMap.forEach(BiConsumer) or re-using the Map.Entry passed to the consumer in entrySet().forEach(Consumer)? > > That's a very good idea. Why not adding the following default method to Map interface: > > default void forEach(BiConsumer sink) { > for (Map.Entry entry : entrySet()) { > sink.apply(entry.getKey(), entry.getValue()); > } > } > It's already there :-) http://download.java.net/jdk8/docs/api/java/util/Map.html#forEach(java.util.function.BiConsumer) Just need some Map impls to override it. I logged a bug, JDK-8016446, to track it. Paul. > ...and override it in IHM, HM/LHM, CHM with optimal implementations... > > Regards, Peter > >> >> Mike >> >>> cheers, >>> R?mi > From paul.sandoz at oracle.com Wed Jun 12 08:41:11 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 10:41:11 +0200 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: <51B7896A.70109@oracle.com> References: <51B7896A.70109@oracle.com> Message-ID: Looks ok to me in my unofficial reviewer role. Paul. On Jun 11, 2013, at 10:32 PM, Brent Christian wrote: > Hi, > > Please review my fix for 8010325. Some background: > > The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value. > > Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used. > > By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed. > > The webrev is here: > http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e > 2. http://bugs.sun.com/view_bug.do?bug_id=8005698 > 3. http://bugs.sun.com/view_bug.do?bug_id=8005704 From alan.bateman at oracle.com Wed Jun 12 08:47:43 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 12 Jun 2013 08:47:43 +0000 Subject: hg: jdk8/tl/jdk: 8016369: java/lang/instrument/RetransformBigClass.sh failing again Message-ID: <20130612084757.7BEE748171@hg.openjdk.java.net> Changeset: 6df79b7bae6f Author: alanb Date: 2013-06-12 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df79b7bae6f 8016369: java/lang/instrument/RetransformBigClass.sh failing again Reviewed-by: sla, sergei ! test/java/lang/instrument/MakeJAR4.sh From Alan.Bateman at oracle.com Wed Jun 12 09:01:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jun 2013 10:01:10 +0100 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: <51B7896A.70109@oracle.com> References: <51B7896A.70109@oracle.com> Message-ID: <51B838D6.9000707@oracle.com> On 11/06/2013 21:32, Brent Christian wrote: > Hi, > > Please review my fix for 8010325. Some background: > > The alternative string-hashing implementation[1] added to > java.lang.String a new public method, hash32(), as well as a new > private int field to cache the alternate hash value. > > Following 8005698 [2] and 8005704 [3], the new method and field in > String are no longer used. > > By updating a couple lines in Hashtable/HashMap/WeakHashMap, the > internal sun.misc.Hashing class can also be removed. > > The webrev is here: > http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ This looks good to me (and nice to have the footprint of String reduced). -Alan From paul.sandoz at oracle.com Wed Jun 12 09:11:36 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 11:11:36 +0200 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> References: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> Message-ID: <5B706344-F8DC-4C72-80CD-69DBEB6DA77D@oracle.com> I did a quick scan, looks OK. Paul. On Jun 11, 2013, at 1:36 AM, Mike Duigou wrote: > I've done some further updates based upon feedback. I believe this is now "done" and ready for final review. > > http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/ > > I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods. > > Mike > > > On Jun 7 2013, at 10:58 , Mike Duigou wrote: > >> Hello all; >> >> I've incorporated feedback from previous rounds and expect to finalize this addition soon. >> >> http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/ >> >> Any review feedback or suggestions of additional tests welcome. >> >> Thanks, >> >> Mike >> >> > From aleksey.shipilev at oracle.com Wed Jun 12 09:15:37 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 12 Jun 2013 02:15:37 -0700 (PDT) Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: <51B7896A.70109@oracle.com> References: <51B7896A.70109@oracle.com> Message-ID: <51B83C39.7080600@oracle.com> On 06/12/2013 12:32 AM, Brent Christian wrote: > The webrev is here: > http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ Looks good. Minor nit: "(0 != seed)", do we really want operands flipped? -Aleksey. From forax at univ-mlv.fr Wed Jun 12 09:20:19 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Jun 2013 11:20:19 +0200 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: References: <51B7896A.70109@oracle.com> Message-ID: <51B83D53.4000903@univ-mlv.fr> On 06/12/2013 10:41 AM, Paul Sandoz wrote: > Looks ok to me in my unofficial reviewer role. > > Paul. like Paul, not an official reviewer; The patch looks good, nice to see that String is on diet. just nitpicking, in HashMap/HashTable readObject, there is no parenthesis in front of the '?', 0 != seed? seed: 1 should be (0 != seed)? seed: 1 cheers, R?mi > On Jun 11, 2013, at 10:32 PM, Brent Christian wrote: > >> Hi, >> >> Please review my fix for 8010325. Some background: >> >> The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value. >> >> Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used. >> >> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed. >> >> The webrev is here: >> http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ >> >> Thanks, >> -Brent >> >> 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e >> 2. http://bugs.sun.com/view_bug.do?bug_id=8005698 >> 3. http://bugs.sun.com/view_bug.do?bug_id=8005704 From forax at univ-mlv.fr Wed Jun 12 09:28:22 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Jun 2013 11:28:22 +0200 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: References: <51B7578B.7010506@univ-mlv.fr> <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> <51B82728.5050703@gmail.com> Message-ID: <51B83F36.3030104@univ-mlv.fr> On 06/12/2013 10:20 AM, Paul Sandoz wrote: > On Jun 12, 2013, at 9:45 AM, Peter Levart wrote: > >> On 06/11/2013 11:06 PM, Mike Duigou wrote: >>> On Jun 11 2013, at 09:59 , Remi Forax wrote: >>> >>>> Hi guys, >>>> This mail was originality sent to lambda-lib EG but Brian ask me to also send it here to not forget. >>>> >>>> We should provide an implementation of forEach for HashMap that avoid to create an Iterator, >>>> HashMap is too common to not have it's dedicated implementation >>> I assume you mean the forEach on the entrySet. >>> >>>> (ArrayList by example has its own implementation of forEach). >>>> >>>> There is also another implementation that should have a specific implementation IdentityHashMap because >>>> entrySet() creates map entries on the fly so having a specific implementation that will not allocatin entries will improve performance >>>> (a lot for big identity hashmap). >>> Are you suggesting adding a IdentityMap.forEach(BiConsumer) or re-using the Map.Entry passed to the consumer in entrySet().forEach(Consumer)? >> That's a very good idea. Why not adding the following default method to Map interface: >> >> default void forEach(BiConsumer sink) { >> for (Map.Entry entry : entrySet()) { >> sink.apply(entry.getKey(), entry.getValue()); >> } >> } >> > It's already there :-) > > http://download.java.net/jdk8/docs/api/java/util/Map.html#forEach(java.util.function.BiConsumer) > > Just need some Map impls to override it. I logged a bug, JDK-8016446, to track it. > > Paul. Thanks Paul, By the way, could you add to the description of the bug that if we override Map.forEach for HashMap we also need to override it for LinkedHashMap. R?mi > >> ...and override it in IHM, HM/LHM, CHM with optimal implementations... >> >> Regards, Peter >> >>> Mike >>> >>>> cheers, >>>> R?mi From david.holmes at oracle.com Wed Jun 12 09:49:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Jun 2013 19:49:46 +1000 Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails intermittently In-Reply-To: <51B73090.5010407@oracle.com> References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com> <51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com> <51B73090.5010407@oracle.com> Message-ID: <51B8443A.7000801@oracle.com> On 12/06/2013 12:13 AM, Ivan Gerasimov wrote: > Chris and David, thanks for review. > > I've updated the test so the threads use CountDownLatch to wait for each > other. > Now, instead of checking whether the 'second' thread has incremented a > count, the 'main' thread waits for it to call countDown(). > If a timeout was elapsed before the call, I assume that the 'second' > thread is suspended and the test passes. I do not advise doing this. The second thread can be suspended inside the CountdownLatch code. When suspend is involved you do not want any direct interaction between the main thread and the thread being suspended. David ----- > Could you please review the updated webrev: > http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/ > > Sincerely, > Ivan > > On 11.06.2013 13:37, Chris Hegarty wrote: >> On 06/11/2013 08:08 AM, David Holmes wrote: >>> On 11/06/2013 1:54 AM, Chris Hegarty wrote: >>>> I'm not sure I ever saw this test fail, but it does look like it has >>>> issues. >>>> >>>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize >>>> across these threads. >>> >>> I don't think that is possible. The main thread wants to reset the count >>> after the suspend has been issued by "first", but once the suspend has >>> been issued the "first" thread can't signal the synchronizer to let the >>> main thread proceed. The poll around isAlive() does address the main >>> issue of a slowly starting thread. >> >> Ah yes, thanks David. In which case I'm fine with the change. >> >>> For completeness the count variable should be volatile as well. >> >> Agreed. >> >> -Chris. >> >>> >>> Cheers, >>> David >>> >>>> -Chris. >>>> >>>> On 10/06/2013 13:51, Ivan Gerasimov wrote: >>>>> Hello everyone! >>>>> >>>>> The test of ThreadGroup.Suspend() was reported to fail on rare >>>>> occasions. >>>>> It can happen on a busy machine that 1 second delay would not be >>>>> enough >>>>> for the second thread to start. >>>>> Then the first thread would suspend only itself and the test would >>>>> fail. >>>>> Earlier, another test was updated for similar reasons [1], [2]. >>>>> >>>>> The proposed test can still report false *positive* results if the >>>>> second thread has had no chance to execute during one second after it >>>>> had started. >>>>> To avoid them there must be a way do distinguish suspended threads. >>>>> >>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/ >>>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748 >>>>> >>>>> >>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033 >>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9 >>>>> >>>>> Sincerely yours, >>>>> Ivan Gerasimov >>>>> >> >> > From dawid.weiss at gmail.com Wed Jun 12 10:36:10 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 12 Jun 2013 12:36:10 +0200 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <51B82728.5050703@gmail.com> References: <51B7578B.7010506@univ-mlv.fr> <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> <51B82728.5050703@gmail.com> Message-ID: > default void forEach(BiConsumer sink) { It would be nice to specify it as in here: http://labs.carrotsearch.com/download/hppc/0.4.1/api/com/carrotsearch/hppc/ObjectObjectOpenHashMap.html#forEach(T) public > T forEach(T sink) funny as it looks, it allows the caller to create an anonymous class instance and get at its methods/ fields in a call chain. int counted = map.forEach(new BiConsumer() { public int counter; // the rest of the implementation... }).counter; Just a thought. Dawid From Alan.Bateman at oracle.com Wed Jun 12 10:41:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jun 2013 03:41:12 -0700 (PDT) Subject: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <51B68F95.9060109@oracle.com> References: <51B68F95.9060109@oracle.com> Message-ID: <51B85048.8060702@oracle.com> On 11/06/2013 03:46, Mandy Chung wrote: > This adds jdeps --format=dot option to print the output in dot-style > format that can be taken to generate a dependency graph. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ > > This also extends --verbose option to take an optional argument > ("class" and "package") to replace the --verbose-level option and > cleans up PlatformClassPath to use java.nio.file. This this good, .dot is very useful. Minor comments PlatformClassPath: home.resolve("lib").toFile().exists() could also be Files.exists(home.resolve("lib")). "if (classes.exists() && classes.isDirectory()) { ... }" can be changed to "if (classes.isDirectory()) { ... }" In Profiles.main (debugging only, not used) then you can probably drop the check for p1 and p2.profile==0 as they aren't needed. -Alan. From paul.sandoz at oracle.com Wed Jun 12 10:48:34 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 12:48:34 +0200 Subject: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <51B68F95.9060109@oracle.com> References: <51B68F95.9060109@oracle.com> Message-ID: <27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com> Hi Mandy, JdepsTask: Given that the dot graph output is likely to be just as human readable as your original format it is very tempting just to support that format. In fact it is likely to be more human readable since the output is of a known syntax. So IMHO we don't need a format option and dot graph output is sufficient. 636 log.format("digraph G {%n"); Perhaps a better name can be chosen for the title of the summary graph? You don't need to pass in the log PrintWriter to the OutputWriter implementations if they are non-static i.e. sometimes you use "out" and sometimes you use "log". PlatformClassPath: 53 static boolean contains(Archive archive) { 54 return javaHomeArchives.contains(archive) && !archive.getFileName().equals("jfxrt.jar"); 55 } Just curious: why is the the check for "jfxrt.jar" required? Profiles: You might be able to use a lambda expression when creating the comparator for the TreeSet: Set profiles = new TreeSet((p1, p2) -> { ... }); I realize that is just for debugging so it's not really important, but i have lambda goggles on so cannot help it :-) Paul. On Jun 11, 2013, at 4:46 AM, Mandy Chung wrote: > This adds jdeps --format=dot option to print the output in dot-style format that can be taken to generate a dependency graph. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ > > This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file. > > thanks > Mandy From paul.sandoz at oracle.com Wed Jun 12 10:50:50 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 12:50:50 +0200 Subject: forEach on HashMap and IdentityHashMap In-Reply-To: <51B83F36.3030104@univ-mlv.fr> References: <51B7578B.7010506@univ-mlv.fr> <311A449D-516A-4F14-AE4D-21DF6DAB377C@oracle.com> <51B82728.5050703@gmail.com> <51B83F36.3030104@univ-mlv.fr> Message-ID: On Jun 12, 2013, at 11:28 AM, Remi Forax wrote: > By the way, could you add to the description of the bug that if we override Map.forEach for HashMap we also need to override it for LinkedHashMap. > Done. Paul. From Alan.Bateman at oracle.com Wed Jun 12 11:16:59 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jun 2013 12:16:59 +0100 Subject: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com> References: <51B68F95.9060109@oracle.com> <27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com> Message-ID: <51B858AB.5010303@oracle.com> On 12/06/2013 11:48, Paul Sandoz wrote: > : > > You might be able to use a lambda expression when creating the comparator for the TreeSet: > > Set profiles = new TreeSet((p1, p2) -> { ... }); > > I realize that is just for debugging so it's not really important, but i have lambda goggles on so cannot help it :-) > That would be nice but as jdeps is in the langtools repository so I assume it is compiled by the boot JDK. -Alan. From paul.sandoz at oracle.com Wed Jun 12 11:19:06 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 13:19:06 +0200 Subject: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <51B858AB.5010303@oracle.com> References: <51B68F95.9060109@oracle.com> <27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com> <51B858AB.5010303@oracle.com> Message-ID: On Jun 12, 2013, at 1:16 PM, Alan Bateman wrote: > On 12/06/2013 11:48, Paul Sandoz wrote: >> : >> >> You might be able to use a lambda expression when creating the comparator for the TreeSet: >> >> Set profiles = new TreeSet((p1, p2) -> { ... }); >> >> I realize that is just for debugging so it's not really important, but i have lambda goggles on so cannot help it :-) >> > That would be nice but as jdeps is in the langtools repository so I assume it is compiled by the boot JDK. > Drat, i thought there might be a restriction on such code due to that. Paul. From paul.sandoz at oracle.com Wed Jun 12 11:43:41 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 13:43:41 +0200 Subject: jdeps -c/--classpath Re: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <51B68F95.9060109@oracle.com> References: <51B68F95.9060109@oracle.com> Message-ID: <8567E97E-F72E-4BD1-8162-9DD877CABC44@oracle.com> Hi Mandy, Regarding the command line arguments of jdeps, would it not be more consistent to re-use the same classpath related arguments as javac/java/javap/javah "-c" becomes "-cp" "--classpath" becomes "-classpath" ? Paul. On Jun 11, 2013, at 4:46 AM, Mandy Chung wrote: > This adds jdeps --format=dot option to print the output in dot-style format that can be taken to generate a dependency graph. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ > > This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file. > > thanks > Mandy From fweimer at redhat.com Wed Jun 12 13:19:32 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 12 Jun 2013 15:19:32 +0200 Subject: Status update: BigInteger performance enhancements In-Reply-To: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> References: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> Message-ID: <51B87564.9090101@redhat.com> On 06/11/2013 11:31 PM, Brian Burkhalter wrote: > Work on threshold evaluation and the review and validation testing of phase 3 will continue in parallel with other work, some of which will likely affect the same code in which case the changes will be merged. Have you already considered the impact on RSA signing and verification with typical key sizes? -- Florian Weimer / Red Hat Product Security Team From paul.sandoz at oracle.com Wed Jun 12 13:26:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 15:26:14 +0200 Subject: RFR 8016455: Sync stream tests from lambda to tl Message-ID: Hi, This patch synchronizes the test framework and many of the tests from lambda to tl and improves: 1) the asserting of results, indicating whether the result to assert on has an encounter order and was computed in parallel. This will become more relevant when the improvements to the limit operation are submitted to tl. 2) the setting of a context when a test method performs multiple tests, such that when failure occurs that context is logged and it is easier to determine what failed. http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/ Paul. From chris.hegarty at oracle.com Wed Jun 12 13:51:35 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 12 Jun 2013 13:51:35 +0000 Subject: hg: jdk8/tl/jaxws: 8013021: Rebase 8005432 & 8003542 against the latest jdk8/jaxws; ... Message-ID: <20130612135138.E03F84818A@hg.openjdk.java.net> Changeset: 8f2986ff0235 Author: mkos Date: 2013-06-12 14:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8f2986ff0235 8013021: Rebase 8005432 & 8003542 against the latest jdk8/jaxws 8003542: Improve processing of MTOM attachments 8005432: Update access to JAX-WS Reviewed-by: mullan ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java ! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java ! src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java ! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/XmlSchemaGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/CommonResourceBundle.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/Decoder.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BASE64EncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BooleanEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/BuiltInEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/FloatEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/algorithm/HexadecimalEncodingAlgorithm.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/dom/DOMDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/resources/ResourceBundle.properties ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/sax/AttributesHolder.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/sax/SAXDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/StAXDocumentParser.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/events/StartElementEvent.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/stax/factory/StAXOutputFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/tools/SAXEventSerializer.java ! src/share/jaxws_classes/com/sun/xml/internal/fastinfoset/tools/TransformInputOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/DataHead.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/MemoryData.java + src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/mimepull/TempFiles.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/databinding/DatabindingConfig.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/pipe/Fiber.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/MetroConfigLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/TubeCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/SEIPortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/dispatch/DispatchImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SyncMethodHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingFactoryImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/db/DatabindingImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/DispatchMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/dispatch.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/JAXBWrapperAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/javax/xml/soap/FactoryFinder.java ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java ! src/share/jaxws_classes/javax/xml/soap/SAAJMetaFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnectionFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java From paul.sandoz at oracle.com Wed Jun 12 14:18:09 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 16:18:09 +0200 Subject: RFR 8009736: Comparator API cleanup In-Reply-To: <51B790E6.6020209@oracle.com> References: <51B790E6.6020209@oracle.com> Message-ID: <0CE8FB8C-E4A6-44C0-B845-8603601ED75B@oracle.com> Hi Henry, If you don't mind could you hold off on committing this one until the following have gone through to tl: http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/ as there is a delicate balance here to group the code into meaningful units for review and it's awkward to shuffle/update things. I rebased your patch off my patch queue, only one conflict required fixing. I can send you that queue in another email. Is that OK for you? -- Comparator.reverseOrder + *

    The returned comparator is serializable. Try to compare null with + * returned comparator will throw {@link NullPointerException}. + * Typo "Try to compare" (and to . Do you mean: The compare method of the returned comparator will throw a {@link NullPointerException} if a {@code null} value is passed as the second parameter. ? Perhaps add a "@See Collections#reverseOrder" and vice versa on that method. Similar issue for Comparator.naturalOrder but for null passed as the first parameter. Comparators.comparing. Rather than "For example" you can use @apiNote .e.g * @apiNote * To obtain a .... The ToIntFunction accepting method has an example where as the long and double methods to not, perhaps just remove it. Comparators.NullComparator The "real" field can never be null: + NullComparator(int sign, Comparator real) { + this.sign = sign; + this.real = (Comparator) Objects.requireNonNull(real); + } but you are checking for null in the compare method + @Override + public int compare(T a, T b) { + if (a == null) { + return (b == null) ? 0 : sign; + } else if (b == null) { + return -sign; + } else { + return (real == null) ? 0 : real.compare(a, b); // <---- null check + } + } Map.comparingByKey/Value(Comparator cmp) You don't mention "Note that a null key/value..." test/java/util/Comparator/BasicTest.java test/java/util/Comparator/TypeTest.java Has the wrong license header: + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. should be: + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Thanks, Paul. On Jun 11, 2013, at 11:04 PM, Henry Jen wrote: > Hi, > > Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/ > > Highlight of changes, > > - Comparators class is now only package-private implementations. The > public static methods have been move to other arguably more appropriate > places, mostly in Comparator. > > - Comparator.reverseOrder() is renamed to Comparator.reversed() > > - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to > wrap up a comparator to be null-friendly. > > To see the API changes, found the specdiff at > http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html > > Cheers, > Henry From chris.hegarty at oracle.com Wed Jun 12 14:50:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Jun 2013 15:50:09 +0100 Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) Message-ID: <51B88AA1.4090701@oracle.com> Add implementations of parallelPrefix() in Arrays for Object, int, long, and double arrays. Specdiff: http://cr.openjdk.java.net/~chegar/8012647/ver.00/specdiff/java/util/Arrays.html Webrev: http://cr.openjdk.java.net/~chegar/8012647/ver.00/webrev/ This work was done over in the lambda forest mainly by Doug Lea, with some small spec updates by myself. Note: Some work still need to be done to clean up the test, but I would like to focus mainly on the API and try to get it finalized first. -Chris. From brian.burkhalter at oracle.com Wed Jun 12 15:17:38 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 12 Jun 2013 08:17:38 -0700 Subject: Status update: BigInteger performance enhancements In-Reply-To: <51B87564.9090101@redhat.com> References: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> <51B87564.9090101@redhat.com> Message-ID: On Jun 12, 2013, at 6:19 AM, Florian Weimer wrote: > On 06/11/2013 11:31 PM, Brian Burkhalter wrote: > >> Work on threshold evaluation and the review and validation testing of phase 3 will continue in parallel with other work, some of which will likely affect the same code in which case the changes will be merged. > > Have you already considered the impact on RSA signing and verification with typical key sizes? > > -- > Florian Weimer / Red Hat Product Security Team No, but any specific suggestions you might have for this would be appreciated. Thanks, Brian From paul.sandoz at oracle.com Wed Jun 12 15:38:49 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 17:38:49 +0200 Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) In-Reply-To: <51B88AA1.4090701@oracle.com> References: <51B88AA1.4090701@oracle.com> Message-ID: <04E115B7-85CB-46C1-B511-DBB36A5A4BBE@oracle.com> On Jun 12, 2013, at 4:50 PM, Chris Hegarty wrote: > Add implementations of parallelPrefix() in Arrays for Object, int, long, and double arrays. > > Specdiff: > http://cr.openjdk.java.net/~chegar/8012647/ver.00/specdiff/java/util/Arrays.html > Webrev: > http://cr.openjdk.java.net/~chegar/8012647/ver.00/webrev/ > > This work was done over in the lambda forest mainly by Doug Lea, with some small spec updates by myself. > The API looks fine to me. The example text could be moved to an @apiNote. > Note: Some work still need to be done to clean up the test, but I would like to focus mainly on the API and try to get it finalized first. > OK, i will still note some comments on the test: 1) it could be better named; 2) uses random data, and if a test fails there is no way to reproduce from that data; and 3) Could use a sprinkling of @DataProvider for various sizes, taking into account the threshold, minimum partition size and ForkJoinPool.getCommonPoolParallelism(). Paul. From henry.jen at Oracle.com Wed Jun 12 15:54:28 2013 From: henry.jen at Oracle.com (Henry Jen) Date: Wed, 12 Jun 2013 08:54:28 -0700 Subject: RFR 8009736: Comparator API cleanup In-Reply-To: <0CE8FB8C-E4A6-44C0-B845-8603601ED75B@oracle.com> References: <51B790E6.6020209@oracle.com> <0CE8FB8C-E4A6-44C0-B845-8603601ED75B@oracle.com> Message-ID: <398D4E28-9160-45BA-AFE0-C07B768A1AD8@Oracle.com> On Jun 12, 2013, at 7:18 AM, Paul Sandoz wrote: > Hi Henry, > > If you don't mind could you hold off on committing this one until the following have gone through to tl: > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/ > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/ > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/ > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/ > > as there is a delicate balance here to group the code into meaningful units for review and it's awkward to shuffle/update things. > > I rebased your patch off my patch queue, only one conflict required fixing. I can send you that queue in another email. Is that OK for you? > Sure. > -- > > Comparator.reverseOrder > > + *

    The returned comparator is serializable. Try to compare null with > + * returned comparator will throw {@link NullPointerException}. > + * > > Typo "Try to compare" (and to . Do you mean: > > The compare method of the returned comparator will throw a {@link NullPointerException} if a {@code null} value is passed as the second parameter. > > ? > > Perhaps add a "@See Collections#reverseOrder" and vice versa on that method. > > Similar issue for Comparator.naturalOrder but for null passed as the first parameter. > Is "compare null using" better then "compare null with"? null passed as an argument will cause NPE on returned comparator, regardless position. > > Comparators.comparing. > > Rather than "For example" you can use @apiNote .e.g > > * @apiNote > * To obtain a .... > > The ToIntFunction accepting method has an example where as the long and double methods to not, perhaps just remove it. > Make sense. I have #see for comparing(Function), should be clear enough. > > Comparators.NullComparator > > The "real" field can never be null: > > + NullComparator(int sign, Comparator real) { > + this.sign = sign; > + this.real = (Comparator) Objects.requireNonNull(real); > + } > > but you are checking for null in the compare method > > + @Override > + public int compare(T a, T b) { > + if (a == null) { > + return (b == null) ? 0 : sign; > + } else if (b == null) { > + return -sign; > + } else { > + return (real == null) ? 0 : real.compare(a, b); // <---- null check > + } > + } > Hmm, I missed this one. Thanks. > > Map.comparingByKey/Value(Comparator cmp) > > You don't mention "Note that a null key/value?" > That's because null is handled by Comparator in this case, if the Comparator is null-friendly, it is fine. Perhaps I should make that clear. > > test/java/util/Comparator/BasicTest.java > test/java/util/Comparator/TypeTest.java > > Has the wrong license header: > > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. Oracle designates this > + * particular file as subject to the "Classpath" exception as provided > + * by Oracle in the LICENSE file that accompanied this code. > > should be: > > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > WIll fix. Thanks for review. Cheers, Henry From chris.hegarty at oracle.com Wed Jun 12 15:58:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Jun 2013 16:58:08 +0100 Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) In-Reply-To: <04E115B7-85CB-46C1-B511-DBB36A5A4BBE@oracle.com> References: <51B88AA1.4090701@oracle.com> <04E115B7-85CB-46C1-B511-DBB36A5A4BBE@oracle.com> Message-ID: <51B89A90.3080509@oracle.com> On 12/06/2013 16:38, Paul Sandoz wrote: > > On Jun 12, 2013, at 4:50 PM, Chris Hegarty wrote: > >> Add implementations of parallelPrefix() in Arrays for Object, int, long, and double arrays. >> >> Specdiff: >> http://cr.openjdk.java.net/~chegar/8012647/ver.00/specdiff/java/util/Arrays.html >> Webrev: >> http://cr.openjdk.java.net/~chegar/8012647/ver.00/webrev/ >> >> This work was done over in the lambda forest mainly by Doug Lea, with some small spec updates by myself. >> > > The API looks fine to me. Thanks Paul. > The example text could be moved to an @apiNote. Yes, possibly. >> Note: Some work still need to be done to clean up the test, but I would like to focus mainly on the API and try to get it finalized first. >> > > OK, i will still note some comments on the test: > > 1) it could be better named; Agreed. > 2) uses random data, and if a test fails there is no way to reproduce from that data; and Yes this is a problem, and needs to be fixed. > 3) Could use a sprinkling of @DataProvider for various sizes, taking into account the threshold, minimum partition size and ForkJoinPool.getCommonPoolParallelism(). Good idea. Let's finalize the API, start CCC, and I can refactor/cleanup the test in the lambda forest concurrently. -Chris > > Paul. > From Alan.Bateman at oracle.com Wed Jun 12 16:07:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jun 2013 17:07:12 +0100 Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum) In-Reply-To: <51B88AA1.4090701@oracle.com> References: <51B88AA1.4090701@oracle.com> Message-ID: <51B89CB0.3080503@oracle.com> On 12/06/2013 15:50, Chris Hegarty wrote: > Add implementations of parallelPrefix() in Arrays for Object, int, > long, and double arrays. > > Specdiff: > > http://cr.openjdk.java.net/~chegar/8012647/ver.00/specdiff/java/util/Arrays.html > > Webrev: > http://cr.openjdk.java.net/~chegar/8012647/ver.00/webrev/ > > This work was done over in the lambda forest mainly by Doug Lea, with > some small spec updates by myself. > > Note: Some work still need to be done to clean up the test, but I > would like to focus mainly on the API and try to get it finalized first. > > -Chris. Is the name final? Just curious if other names such as parallelScan have been considered (and discarded). "Cumulates in parallel each element ...", I guess I would put a comma before and after "in parallel". Otherwise the API looks good to me. -Alan. From sean.mullan at oracle.com Wed Jun 12 16:10:08 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Jun 2013 12:10:08 -0400 Subject: Status update: BigInteger performance enhancements In-Reply-To: References: <61B06A70-C579-4854-BF74-C35BB73456CC@oracle.com> <51B87564.9090101@redhat.com> Message-ID: <51B89D60.4060708@oracle.com> (cc-ing security-dev for comments) Original thread is at http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017912.html --Sean On 06/12/2013 11:17 AM, Brian Burkhalter wrote: > > On Jun 12, 2013, at 6:19 AM, Florian Weimer wrote: > >> On 06/11/2013 11:31 PM, Brian Burkhalter wrote: >> >>> Work on threshold evaluation and the review and validation testing of phase 3 will continue in parallel with other work, some of which will likely affect the same code in which case the changes will be merged. >> >> Have you already considered the impact on RSA signing and verification with typical key sizes? >> >> -- >> Florian Weimer / Red Hat Product Security Team > > No, but any specific suggestions you might have for this would be appreciated. > > Thanks, > > Brian > From mike.duigou at oracle.com Wed Jun 12 16:10:40 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 12 Jun 2013 09:10:40 -0700 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: <51B7896A.70109@oracle.com> References: <51B7896A.70109@oracle.com> Message-ID: Looks good to me. Mike On Jun 11 2013, at 13:32 , Brent Christian wrote: > Hi, > > Please review my fix for 8010325. Some background: > > The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value. > > Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used. > > By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed. > > The webrev is here: > http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e > 2. http://bugs.sun.com/view_bug.do?bug_id=8005698 > 3. http://bugs.sun.com/view_bug.do?bug_id=8005704 From mandy.chung at oracle.com Wed Jun 12 16:19:52 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 12 Jun 2013 09:19:52 -0700 (PDT) Subject: jdeps -c/--classpath Re: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <8567E97E-F72E-4BD1-8162-9DD877CABC44@oracle.com> References: <51B68F95.9060109@oracle.com> <8567E97E-F72E-4BD1-8162-9DD877CABC44@oracle.com> Message-ID: <51B89FA8.5090208@oracle.com> On 6/12/13 4:43 AM, Paul Sandoz wrote: > Hi Mandy, > > Regarding the command line arguments of jdeps, would it not be more consistent to re-use the same classpath related arguments as javac/java/javap/javah > > "-c" becomes "-cp" > "--classpath" becomes "-classpath" > > ? jdeps follows the GNU-style options which is different than the JDK style. We discussed this issue about consistency and familiarity [1]. After using jdeps for some time, I admit that I find it hard to switch to the new -c short option (and confusing too) but relatively easy to move to --classpath option. Mixing both GNU-style and JDK-style inconsistently adopting GNU style is not a good thing while GNU style is the direction we are going (e.g. pack200 follows GNU style). Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012989.html and its thread. > > Paul. > > On Jun 11, 2013, at 4:46 AM, Mandy Chung wrote: > >> This adds jdeps --format=dot option to print the output in dot-style format that can be taken to generate a dependency graph. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/ >> >> This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file. >> >> thanks >> Mandy From brent.christian at oracle.com Wed Jun 12 16:30:30 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 12 Jun 2013 09:30:30 -0700 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: References: <51B7896A.70109@oracle.com> Message-ID: <51B8A226.8010205@oracle.com> Thanks for the reviews, everyone. I will change the nits mentioned. And I need a sponsor. Thanks, -Brent On 6/12/13 9:10 AM, Mike Duigou wrote: > Looks good to me. > > Mike > > On Jun 11 2013, at 13:32 , Brent Christian wrote: > >> Hi, >> >> Please review my fix for 8010325. Some background: >> >> The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value. >> >> Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used. >> >> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed. >> >> The webrev is here: >> http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/ >> >> Thanks, >> -Brent >> >> 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e >> 2. http://bugs.sun.com/view_bug.do?bug_id=8005698 >> 3. http://bugs.sun.com/view_bug.do?bug_id=8005704 > From paul.sandoz at oracle.com Wed Jun 12 16:36:59 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 18:36:59 +0200 Subject: RFR 8009736: Comparator API cleanup In-Reply-To: <398D4E28-9160-45BA-AFE0-C07B768A1AD8@Oracle.com> References: <51B790E6.6020209@oracle.com> <0CE8FB8C-E4A6-44C0-B845-8603601ED75B@oracle.com> <398D4E28-9160-45BA-AFE0-C07B768A1AD8@Oracle.com> Message-ID: <55A1615D-1543-4E58-8DF1-10F31EC607F3@oracle.com> On Jun 12, 2013, at 5:54 PM, Henry Jen wrote: >> >> Comparator.reverseOrder >> >> + *

    The returned comparator is serializable. Try to compare null with >> + * returned comparator will throw {@link NullPointerException}. >> + * >> >> Typo "Try to compare" (and to . Do you mean: >> >> The compare method of the returned comparator will throw a {@link NullPointerException} if a {@code null} value is passed as the second parameter. >> >> ? >> >> Perhaps add a "@See Collections#reverseOrder" and vice versa on that method. >> >> Similar issue for Comparator.naturalOrder but for null passed as the first parameter. >> > > Is "compare null using" better then "compare null with"? > It's more the tense of the sentence. How about: "The returned comparator is serializable and does not permit null arguments when comparing objects". ? > null passed as an argument will cause NPE on returned comparator, regardless position. > Doh!, of course :-) Comparable.compare(null) should also throw an NPE, just the stack trace will be slightly different. >> Map.comparingByKey/Value(Comparator cmp) >> >> You don't mention "Note that a null key/value?" >> > > That's because null is handled by Comparator in this case, if the Comparator is null-friendly, it is fine. Perhaps I should make that clear. Ah, yes, some clarification would be useful. Paul. From mike.duigou at oracle.com Wed Jun 12 16:43:58 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 12 Jun 2013 09:43:58 -0700 Subject: RFR 8016455: Sync stream tests from lambda to tl In-Reply-To: References: Message-ID: <74070E15-C1AB-429E-A766-DE790AE27009@oracle.com> Looks good to me. Mike On Jun 12 2013, at 06:26 , Paul Sandoz wrote: > Hi, > > This patch synchronizes the test framework and many of the tests from lambda to tl and improves: > > 1) the asserting of results, indicating whether the result to assert on has an encounter order and was computed in parallel. This will become more relevant when the improvements to the limit operation are submitted to tl. > > 2) the setting of a context when a test method performs multiple tests, such that when failure occurs that context is logged and it is easier to determine what failed. > > http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/ > > Paul. From paul.sandoz at oracle.com Wed Jun 12 16:51:19 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 12 Jun 2013 18:51:19 +0200 Subject: jdeps -c/--classpath Re: Review request JDK-8015912: jdeps support to output in dot file format In-Reply-To: <51B89FA8.5090208@oracle.com> References: <51B68F95.9060109@oracle.com> <8567E97E-F72E-4BD1-8162-9DD877CABC44@oracle.com> <51B89FA8.5090208@oracle.com> Message-ID: On Jun 12, 2013, at 6:19 PM, Mandy Chung wrote: > On 6/12/13 4:43 AM, Paul Sandoz wrote: >> Hi Mandy, >> >> Regarding the command line arguments of jdeps, would it not be more consistent to re-use the same classpath related arguments as javac/java/javap/javah >> >> "-c" becomes "-cp" >> "--classpath" becomes "-classpath" >> >> ? > > jdeps follows the GNU-style options which is different than the JDK style. We discussed this issue about consistency and familiarity [1]. After using jdeps for some time, I admit that I find it hard to switch to the new -c short option (and confusing too) but relatively easy to move to --classpath option. Mixing both GNU-style and JDK-style inconsistently adopting GNU style is not a good thing while GNU style is the direction we are going (e.g. pack200 follows GNU style). Agreed mixing both is bad. Most developers will never use pack200, so arguably familiarity using JDK style trumps moving to the GNU style IMHO. But i will not press the issue if the ship has sailed on GNU style for new commands. Paul. From martinrb at google.com Wed Jun 12 17:45:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Jun 2013 10:45:03 -0700 Subject: RFR 8010325 : Remove hash32() method and hash32 int field from java.lang.String In-Reply-To: <51B7896A.70109@oracle.com> References: <51B7896A.70109@oracle.com> Message-ID: Hi Brent, Thanks for doing this. Your webrev does not include mercurial changeset information, which I think is supported by recent webrevs. I assume you've been working with Doug Lea on this. If not, the two of you should talk. BTW, it's sad not to see things like murmur hash be public supported algorithms - but I think guava provides it. On Tue, Jun 11, 2013 at 1:32 PM, Brent Christian wrote: > Hi, > > Please review my fix for 8010325. Some background: > > The alternative string-hashing implementation[1] added to java.lang.String > a new public method, hash32(), as well as a new private int field to cache > the alternate hash value. > > Following 8005698 [2] and 8005704 [3], the new method and field in String > are no longer used. > > By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal > sun.misc.Hashing class can also be removed. > > The webrev is here: > http://cr.openjdk.java.net/~**bchristi/8010325/webrev.00/ > > Thanks, > -Brent > > 1. http://hg.openjdk.java.net/**jdk8/jdk8/jdk/rev/43bd5ee0205e > 2. http://bugs.sun.com/view_bug.**do?bug_id=8005698 > 3. http://bugs.sun.com/view_bug.**do?bug_id=8005704 > From stevenschlansker at gmail.com Wed Jun 12 18:27:33 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Wed, 12 Jun 2013 11:27:33 -0700 Subject: Dismal performance of String.intern() In-Reply-To: <51B6E53A.4060107@oracle.com> References: <51B6E05F.9080700@univ-mlv.fr> <51B6E53A.4060107@oracle.com> Message-ID: <1323139C-EE46-4402-A5CF-96A0471C4011@gmail.com> Thank you everyone for the valuable input! On Jun 11, 2013, at 1:52 AM, Aleksey Shipilev wrote: > On 06/11/2013 12:31 PM, Remi Forax wrote: >> On 06/10/2013 08:06 PM, Steven Schlansker wrote: >> Hi Steven, >> the main issue is that intern() doesn't work in isolation, >> >> I think it's better to change the JSON Parser implementation to use it's >> own cache (or not) and not rely on String.intern(). > > +1. > > IMO, String.intern() is the gateway into VM symbol table, and should be > regarded as such. The improvements for String.intern(), if any, then > should be on the VM (native) side. > > Also, I think most people confuse String interning and String > de-duplication. Using interning to improve memory footprint is the > overkill. Smart deduplicators may carefully balance the overheads of > deduplication vs. the memory footprint Yes, maybe this is in fact the real problem here. The JavaDoc for String does not in anyway reflect what you and the other JDK developers seem to assume -- that intern() is mostly a "for JVM use" method and is not really intended for use by end users. Maybe a documentation update to reflect that fact would be appropriate? Something indicating that the implementation is specialized for VM usage and is not optimal for end user code might help clear up confusion. Does that sound like a good idea? I understand that this is confusing the contract of the method with the implementation a bit. I just feel that the sentiment I get here ("Why would you do that? Don't use intern, just do it yourself!") is mismatched with the implicit fit-for-purpose I expect from core Java classes, and a warning might help reduce confusion. On Jun 11, 2013, at 2:28 AM, Alan Bateman wrote: > On 10/06/2013 19:06, Steven Schlansker wrote: >> Hi core-libs-dev, >> >> While doing performance profiling of my application, I discovered that nearly 50% of the time deserializing JSON was spent within String.intern(). I understand that in general interning Strings is not the best approach for things, but I think I have a decent use case -- the value of a certain field is one of a very limited number of valid values (that are not known at compile time, so I cannot use an Enum), and is repeated many millions of times in the JSON stream. >> > Have you run with -XX:+PrintStringTableStatistics? Might be interesting if you can share the output (it is printed just before the VM terminates). > > There are also tuning knobs such as StringTableSize and would be interesting to know if you've experimented with. > > -Alan. I have not experimented with any such tunings. I will do so and report back before spending a lot of time changing things. Thank you for the pointer! Best, Steven From aleksey.shipilev at oracle.com Wed Jun 12 18:38:20 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 12 Jun 2013 11:38:20 -0700 (PDT) Subject: Dismal performance of String.intern() In-Reply-To: <1323139C-EE46-4402-A5CF-96A0471C4011@gmail.com> References: <51B6E05F.9080700@univ-mlv.fr> <51B6E53A.4060107@oracle.com> <1323139C-EE46-4402-A5CF-96A0471C4011@gmail.com> Message-ID: <51B8C01C.9050200@oracle.com> On 06/12/2013 10:27 PM, Steven Schlansker wrote: > Thank you everyone for the valuable input! > > On Jun 11, 2013, at 1:52 AM, Aleksey Shipilev > wrote: > >> On 06/11/2013 12:31 PM, Remi Forax wrote: >>> On 06/10/2013 08:06 PM, Steven Schlansker wrote: Hi Steven, the >>> main issue is that intern() doesn't work in isolation, >>> >>> I think it's better to change the JSON Parser implementation to >>> use it's own cache (or not) and not rely on String.intern(). >> >> +1. >> >> IMO, String.intern() is the gateway into VM symbol table, and >> should be regarded as such. The improvements for String.intern(), >> if any, then should be on the VM (native) side. >> >> Also, I think most people confuse String interning and String >> de-duplication. Using interning to improve memory footprint is the >> overkill. Smart deduplicators may carefully balance the overheads >> of deduplication vs. the memory footprint > > Yes, maybe this is in fact the real problem here. The JavaDoc for > String does not in anyway reflect what you and the other JDK > developers seem to assume -- that intern() is mostly a "for JVM use" > method and is not really intended for use by end users. Maybe a > documentation update to reflect that fact would be appropriate? > Something indicating that the implementation is specialized for VM > usage and is not optimal for end user code might help clear up > confusion. Does that sound like a good idea? Yes, that's a good idea. I'd like to hear the opinions of the real corelibs maintainers though. Again, String.intern() performance improvements are very much welcome, because it is still needed in many cases :) > I understand that this is confusing the contract of the method with > the implementation a bit. I just feel that the sentiment I get here > ("Why would you do that? Don't use intern, just do it yourself!") is > mismatched with the implicit fit-for-purpose I expect from core Java > classes, and a warning might help reduce confusion. I think in JDK 8 timeframe, we could even make a bold move and introduce some other auxiliary method, say, String.deduplicate(), which relax the interning requirement. That will untie us from initialization races, when we can ignore deduplication while VM is still booting, and only then allow e.g. ConcurrentHashMap to load and plug-in to deduplication. Although, I vaguely remember the pending VM improvements for deduplicating String on-the-fly without user hints (really, walk the Strings during full GC), so it might be redundant. -Aleksey. From martinrb at google.com Wed Jun 12 18:49:00 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Jun 2013 11:49:00 -0700 Subject: RFR : 7129185 : (M) Add Collections.{checked|empty|unmodifiable}Navigable{Map|Set} In-Reply-To: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> References: <993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com> Message-ID: Thanks for doing this. Arguably, I or Josh or Doug should have done this for jdk6. It's tedious to get all the details right. Mostly looks good. I suspect the set returned by emptySortedSet is not serialization-compatible between jdk8 and previous jdks. Extending EmptySortedSet to also implement NavigableSet ought to be both more compatible and more efficient. And more tedious! The code fragment below doesn't actually work, cuz WeakHashMap is not a NavigableMap. + * in the following code fragment: + * 

     {@code
+     *    Set weakHashSet =
Collections.newNavigableSetFromNavigableMap(
+     *        new WeakHashMap());
+     * }


It's traditional to only @link to a particular destination once per
javadoc block.

+     * any {@link NavigableMap} implementation.  There is no need to use this
+     * method on a {@link NavigableMap} implementation that already has a




On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou  wrote:

> I've done some further updates based upon feedback. I believe this is now
> "done" and ready for final review.
>
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/
>
> I did find one inconsistency in the implementations SortedSet.headSet and
> SortedSet.tailSet methods.
>
> Mike
>
>
> On Jun 7 2013, at 10:58 , Mike Duigou wrote:
>
> > Hello all;
> >
> > I've incorporated feedback from previous rounds and expect to finalize
> this addition soon.
> >
> > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/
> >
> > Any review feedback or suggestions of additional tests welcome.
> >
> > Thanks,
> >
> > Mike
> >
> >
>
>


From chris.hegarty at oracle.com  Wed Jun 12 19:52:00 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 12 Jun 2013 12:52:00 -0700 (PDT)
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: 
References: <51B7896A.70109@oracle.com>
	
Message-ID: 


On 12 Jun 2013, at 17:10, Mike Duigou  wrote:

> Looks good to me.

+1

-Chris


> Mike
> 
> On Jun 11 2013, at 13:32 , Brent Christian wrote:
> 
>> Hi,
>> 
>> Please review my fix for 8010325.  Some background:
>> 
>> The alternative string-hashing implementation[1] added to java.lang.String a new public method, hash32(), as well as a new private int field to cache the alternate hash value.
>> 
>> Following 8005698 [2] and 8005704 [3], the new method and field in String are no longer used.
>> 
>> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal sun.misc.Hashing class can also be removed.
>> 
>> The webrev is here:
>> http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/
>> 
>> Thanks,
>> -Brent
>> 
>> 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e
>> 2. http://bugs.sun.com/view_bug.do?bug_id=8005698
>> 3. http://bugs.sun.com/view_bug.do?bug_id=8005704
> 


From brian.burkhalter at oracle.com  Wed Jun 12 19:56:53 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 12 Jun 2013 12:56:53 -0700
Subject: RFR 7192954+4396272: Fix Float.parseFloat to round correctly and
	preserve monotonicity
In-Reply-To: 
References: 
Message-ID: <207D3115-6C73-45CA-A597-7EC483542730@oracle.com>

The original patch has been updated such that it also fixes

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7039391 - Use Math.ulp in FloatingDecimal.

The updated patch is at

http://cr.openjdk.java.net/~bpb/7192954_4396272_7039391/

For purposes of comparison, the original patch is left online at the location indicated below.

The specific changes in the update are

1) Use IEEE-754 primitive long instead of primitive double for the candidate double, thereby removing FloatingDecimal.ulp() without using any Math.* methods.

2) Remove strictfp from declarations of doubleValue() and floatValue().

3) In floatValue(), find approximation directly instead of invoking doubleValue().

I have code-reviewed the update and ensured that it passes the JTREG tests in

* sun/misc/FloatingDecimal
* java/lang/Double
* java/lang/Float
* java/math

If there are other pertinent validations which should be performed please point them out.

Once this patch has been officially reviewed I will post the webrev for http://bugs.sun.com/view_bug.do?bug_id=7131192 - BigInteger.doubleValue() is "depressingly" slow.

Thanks,

Brian

On Jun 11, 2013, at 3:47 PM, Brian Burkhalter wrote:

> This contributed patch
> 
> http://cr.openjdk.java.net/~bpb/4396272%2b7192954/
> 
> fixes these two issues:
> 
> 1) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192954 - Fix Float.parseFloat to round correctly and preserve monotonicity
> 
> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272 - Parsing double fails to follow IEEE for largest decimal the should yield 0
> 
> For 7192954, "stickyRound()" is replaced by actual code development containing a correction loop in floatValue() analogous to that in doubleValue().
> 
> For 4396272, when the difference between the scaled big-int versions of the exact value and the candidate double value is exactly 1/2*ULP, and the candidate value <= 2*Double.MIN_NORMAL, then form the correction statement in a way that avoids rounding the intermediate result to zero thereby preventing correction.
> 
> For reference see also this thread:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014788.html
> 
> Thanks,
> 
> Brian



From mike.duigou at oracle.com  Wed Jun 12 20:16:21 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 12 Jun 2013 20:16:21 +0000
Subject: hg: jdk8/tl/jdk: 8010325: Remove hash32() method and hash32 int field
	from java.lang.String
Message-ID: <20130612201643.6DE4C4819E@hg.openjdk.java.net>

Changeset: c9f5a2fd7d3d
Author:    bchristi
Date:      2013-06-12 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9f5a2fd7d3d

8010325: Remove hash32() method and hash32 int field from java.lang.String
Reviewed-by: alanb, mduigou

! src/share/classes/java/lang/String.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/WeakHashMap.java
- src/share/classes/sun/misc/Hashing.java
- test/sun/misc/Hashing.java



From chris.hegarty at oracle.com  Wed Jun 12 20:30:27 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 12 Jun 2013 13:30:27 -0700 (PDT)
Subject: jdeps -c/--classpath  Re: Review request JDK-8015912: jdeps
	support to output in dot file format
In-Reply-To: <51B89FA8.5090208@oracle.com>
References: <51B68F95.9060109@oracle.com>
	<8567E97E-F72E-4BD1-8162-9DD877CABC44@oracle.com>
	<51B89FA8.5090208@oracle.com>
Message-ID: 


>>> Webrev at:
>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/

Looks ok to me.

-Chris.

>>> 
>>> This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file.
>>> 
>>> thanks
>>> Mandy
> 


From henry.jen at oracle.com  Wed Jun 12 20:48:06 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 12 Jun 2013 13:48:06 -0700
Subject: RFR: 8016448: java/util/BitSet/BitSetStreamTest.java no longer
	compiles, missed by 8015895
Message-ID: <51B8DE86.1060002@oracle.com>

Hi,

Please review a simple fix for 8016448, a test case missed from a API
change commit.

http://cr.openjdk.java.net/~henryjen/tl/8016448.0/webrev/

Cheers,
Henry


From mike.duigou at oracle.com  Wed Jun 12 20:54:48 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 12 Jun 2013 13:54:48 -0700
Subject: RFR: 8016448: java/util/BitSet/BitSetStreamTest.java no longer
	compiles, missed by 8015895
In-Reply-To: <51B8DE86.1060002@oracle.com>
References: <51B8DE86.1060002@oracle.com>
Message-ID: <4C5BC85E-D76E-4758-A027-60713CFC2726@oracle.com>

It doesn't test quite the same thing but looks fine. ie. the contents of the ranges change.

Mike

On Jun 12 2013, at 13:48 , Henry Jen wrote:

> Hi,
> 
> Please review a simple fix for 8016448, a test case missed from a API
> change commit.
> 
> http://cr.openjdk.java.net/~henryjen/tl/8016448.0/webrev/
> 
> Cheers,
> Henry



From henry.jen at oracle.com  Wed Jun 12 20:58:38 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 12 Jun 2013 13:58:38 -0700 (PDT)
Subject: RFR: 8016448: java/util/BitSet/BitSetStreamTest.java no longer
	compiles, missed by 8015895
In-Reply-To: <4C5BC85E-D76E-4758-A027-60713CFC2726@oracle.com>
References: <51B8DE86.1060002@oracle.com>
	<4C5BC85E-D76E-4758-A027-60713CFC2726@oracle.com>
Message-ID: <419227C3-C487-4DEF-9A58-94D40B737A5A@oracle.com>

Yes, the test is to make sure the BitSet is correct, the content of the range changes doesn't affect the test.

Cheers,
Henry

On Jun 12, 2013, at 1:54 PM, Mike Duigou  wrote:

> It doesn't test quite the same thing but looks fine. ie. the contents of the ranges change.
> 
> Mike
> 
> On Jun 12 2013, at 13:48 , Henry Jen wrote:
> 
>> Hi,
>> 
>> Please review a simple fix for 8016448, a test case missed from a API
>> change commit.
>> 
>> http://cr.openjdk.java.net/~henryjen/tl/8016448.0/webrev/
>> 
>> Cheers,
>> Henry
> 



From sean.coffey at oracle.com  Wed Jun 12 21:12:16 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 12 Jun 2013 22:12:16 +0100
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: <51B8A226.8010205@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B8A226.8010205@oracle.com>
Message-ID: <51B8E430.2000200@oracle.com>

Brent,

do you need to remove the sun/misc/Hashing.java reference from the 
make/java/java/FILES_java.gmk file? I suspect it could break builds for 
people still using the old build system on jdk8.

regards,
Sean.

On 12/06/13 17:30, Brent Christian wrote:
> Thanks for the reviews, everyone.  I will change the nits mentioned. 
> And I need a sponsor.
>
> Thanks,
> -Brent
>
> On 6/12/13 9:10 AM, Mike Duigou wrote:
>> Looks good to me.
>>
>> Mike
>>
>> On Jun 11 2013, at 13:32 , Brent Christian wrote:
>>
>>> Hi,
>>>
>>> Please review my fix for 8010325.  Some background:
>>>
>>> The alternative string-hashing implementation[1] added to 
>>> java.lang.String a new public method, hash32(), as well as a new 
>>> private int field to cache the alternate hash value.
>>>
>>> Following 8005698 [2] and 8005704 [3], the new method and field in 
>>> String are no longer used.
>>>
>>> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the 
>>> internal sun.misc.Hashing class can also be removed.
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/
>>>
>>> Thanks,
>>> -Brent
>>>
>>> 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e
>>> 2. http://bugs.sun.com/view_bug.do?bug_id=8005698
>>> 3. http://bugs.sun.com/view_bug.do?bug_id=8005704
>>



From mike.duigou at oracle.com  Wed Jun 12 21:23:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 12 Jun 2013 14:23:24 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
Message-ID: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>

Hello all;

This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap

http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/

The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained. 

Mike

From mike.duigou at oracle.com  Wed Jun 12 21:37:53 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 12 Jun 2013 14:37:53 -0700
Subject: 8016251: Balanced spliterator for SpinedBuffer
In-Reply-To: 
References: 
Message-ID: 

Looks good.

Mike

On Jun 10 2013, at 07:40 , Paul Sandoz wrote:

> Hi,
> 
> This patch contains the following changes:
> 
> 1) implements balanced splits for the spliterator of SpinedBuffer, which is contributed by Peter Levart; and

For context, http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009306.html is where Peter proposed this.

> 
> 2) syncs lambda's version SpinedBuffer with tl, hence why there are some other changes they may not be entirely obvious until other code follows later on but will make that process easier e.g. the renaming of asXxxArray to asPrimitiveArray or the method SpinedBuffer.OfPrimitive.newArray changing from protected to public.

Seems OK.

> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/
> 
> Paul.
> 



From brent.christian at oracle.com  Wed Jun 12 21:57:33 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 12 Jun 2013 14:57:33 -0700
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: <51B8E430.2000200@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B8A226.8010205@oracle.com> <51B8E430.2000200@oracle.com>
Message-ID: <51B8EECD.3090509@oracle.com>

Hi, Se?n

I admit that I did not think to update FILES_java.gmk.  A quick informal 
poll indicates that the old build is already broken on jdk8, and has 
been for some time.

Thanks,
-Brent

On 6/12/13 2:12 PM, Se?n Coffey wrote:
> Brent,
>
> do you need to remove the sun/misc/Hashing.java reference from the
> make/java/java/FILES_java.gmk file? I suspect it could break builds for
> people still using the old build system on jdk8.
>
> regards,
> Sean.
>
> On 12/06/13 17:30, Brent Christian wrote:
>> Thanks for the reviews, everyone.  I will change the nits mentioned.
>> And I need a sponsor.
>>
>> Thanks,
>> -Brent
>>
>> On 6/12/13 9:10 AM, Mike Duigou wrote:
>>> Looks good to me.
>>>
>>> Mike
>>>
>>> On Jun 11 2013, at 13:32 , Brent Christian wrote:
>>>
>>>> Hi,
>>>>
>>>> Please review my fix for 8010325.  Some background:
>>>>
>>>> The alternative string-hashing implementation[1] added to
>>>> java.lang.String a new public method, hash32(), as well as a new
>>>> private int field to cache the alternate hash value.
>>>>
>>>> Following 8005698 [2] and 8005704 [3], the new method and field in
>>>> String are no longer used.
>>>>
>>>> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the
>>>> internal sun.misc.Hashing class can also be removed.
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> 1. http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/43bd5ee0205e
>>>> 2. http://bugs.sun.com/view_bug.do?bug_id=8005698
>>>> 3. http://bugs.sun.com/view_bug.do?bug_id=8005704
>>>
>


From mike.duigou at oracle.com  Wed Jun 12 22:34:52 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Wed, 12 Jun 2013 22:34:52 +0000
Subject: hg: jdk8/tl/jdk: 8016448: java/util/BitSet/BitSetStreamTest.java no
	longer compiles, missed by 8015895
Message-ID: <20130612223514.9284D481A3@hg.openjdk.java.net>

Changeset: ce8fbca80bbc
Author:    henryjen
Date:      2013-06-12 14:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce8fbca80bbc

8016448: java/util/BitSet/BitSetStreamTest.java no longer compiles, missed by 8015895
Reviewed-by: mduigou

! test/java/util/BitSet/BitSetStreamTest.java



From forax at univ-mlv.fr  Wed Jun 12 22:49:54 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 00:49:54 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
Message-ID: <51B8FB12.2090901@univ-mlv.fr>

On 06/12/2013 11:23 PM, Mike Duigou wrote:
> Hello all;
>
> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>
> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>
> Mike

Hi Mike,
funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same 
time.
(you need also to override forEach in LinkedHashMap because the one you 
inherits from HashMap doesn't use the linked list of entries).

My code is slightly different from yours because I've moved the cases 
where the item is a red/black tree out of the fast path
(the tree is created either if you are unlucky, if hashCode is badly 
written or if someone forge keys to have collisions)
and does the modCount check for each element because a call to the 
consumer can change the underlying map
so you can not do a modCount check only at the end.

R?mi

Here is the diff.
diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
--- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 
2013 +0100
+++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 
2013 +0200
@@ -28,6 +28,7 @@
  import java.io.*;
  import java.lang.reflect.ParameterizedType;
  import java.lang.reflect.Type;
+import java.util.function.BiConsumer;
  import java.util.function.Consumer;
  import java.util.function.BiFunction;
  import java.util.function.Function;
@@ -2615,6 +2616,54 @@
      int   capacity()     { return table.length; }
      float loadFactor()   { return loadFactor;   }

+
+    @Override
+    public void forEach(BiConsumer action) {
+        Objects.requireNonNull(action);
+        final int expectedModCount = modCount;
+        if (nullKeyEntry != null) {
+            forEachNullKey(expectedModCount, action);
+        }
+        Object[] table = this.table;
+        for(int index = 0; index < table.length; index++) {
+            Object item = table[index];
+            if (item == null) {
+                continue;
+            }
+            if (item instanceof HashMap.TreeBin) {
+                eachTreeNode(expectedModCount, ((TreeBin)item).first, 
action);
+                continue;
+            }
+            @SuppressWarnings("unchecked")
+            Entry entry = (Entry)item;
+            for (;entry != null; entry = (Entry)entry.next) {
+                if (expectedModCount != modCount) {
+                    throw new ConcurrentModificationException();
+                }
+                action.accept(entry.key, entry.value);
+            }
+        }
+    }
+
+    private void eachTreeNode(int expectedModCount, TreeNode node, 
BiConsumer action) {
+        while (node != null) {
+            if (expectedModCount != modCount) {
+                throw new ConcurrentModificationException();
+            }
+            @SuppressWarnings("unchecked")
+            Entry entry = (Entry)node.entry;
+            action.accept(entry.key, entry.value);
+            node = (TreeNode)entry.next;
+        }
+    }
+
+    private void forEachNullKey(int expectedModCount, BiConsumer action) {
+        if (expectedModCount != modCount) {
+            throw new ConcurrentModificationException();
+        }
+        action.accept(null, nullKeyEntry.value);
+    }
+
      /**
       * Standin until HM overhaul; based loosely on Weak and Identity HM.
       */
diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
--- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 
09:44:34 2013 +0100
+++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 
00:46:05 2013 +0200
@@ -24,7 +24,8 @@
   */

  package java.util;
-import java.io.*;
+
+import java.util.function.BiConsumer;

  /**
   * 
    Hash table and linked list implementation of the Map 
interface,
@@ -470,4 +471,16 @@
      protected boolean removeEldestEntry(Map.Entry eldest) {
          return false;
      }
+
+    @Override
+    public void forEach(BiConsumer action) {
+        Objects.requireNonNull(action);
+        int expectedModCount = modCount;
+        for (Entry entry = header.after; entry != header; entry = 
entry.after) {
+            if (expectedModCount != modCount) {
+                throw new ConcurrentModificationException();
+            }
+            action.accept(entry.key, entry.value);
+        }
+    }
  }




From mike.duigou at oracle.com  Wed Jun 12 23:14:19 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 12 Jun 2013 16:14:19 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B8FB12.2090901@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
Message-ID: <6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>


On Jun 12 2013, at 15:49 , Remi Forax wrote:

> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>> Hello all;
>> 
>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>> 
>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>> 
>> Mike
> 
> Hi Mike,
> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.

> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).

I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.

> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)

Yes, this is probably worthwhile

> and does the modCount check for each element because a call to the consumer can change the underlying map
> so you can not do a modCount check only at the end.

Yes, mine wasn't fast fail enough. I am always torn between satisfying those who will moan at the per-element cost and those who will moan about the lack of fast-fail behaviour.

Thank you for the improvements!

Mike

From forax at univ-mlv.fr  Wed Jun 12 23:20:50 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 01:20:50 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
Message-ID: <51B90252.4080702@univ-mlv.fr>

On 06/13/2013 01:14 AM, Mike Duigou wrote:
> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>
>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>
>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>
>>> Mike
>> Hi Mike,
>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>
>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
> Yes, this is probably worthwhile
>
>> and does the modCount check for each element because a call to the consumer can change the underlying map
>> so you can not do a modCount check only at the end.
> Yes, mine wasn't fast fail enough. I am always torn between satisfying those who will moan at the per-element cost and those who will moan about the lack of fast-fail behaviour.

I've not tested (yet) but I'me pretty sure that Hotspot will move the 
modCount test out of the loop if it can see through the lambda that the 
map is not modified. So it's a win-win situation here :)

>
> Thank you for the improvements!
>
> Mike

cheers,
R?mi



From brian.burkhalter at oracle.com  Wed Jun 12 23:45:07 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 12 Jun 2013 16:45:07 -0700
Subject: RFR 8015395: NumberFormatException during startup if
	java.lang.Integer.IntegerCache.high set to bad value
Message-ID: <11B7797E-3D7F-44AC-BD39-DE85282B06E6@oracle.com>

As no consensus was achieved, I am following up on this thread from last month

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017493.html

The behavior with and without the initially suggested patch http://cr.openjdk.java.net/~bpb/8015395/ for a few examples is listed below. As may be seen, the change suppresses the exception for bad values of the java.lang.Integer.IntegerCache.high property passed on the command line (silently falls back to the default value), but appears not to affect the behavior of the AutoBoxCacheMax property for these same values.

There was more support expressed in the thread last month for throwing the NumberFormatExceotion rather than ignoring the bad value and falling back silently to the default. I tend to agree with that approach in general, but I think that the question here is really whether the same logic applies to a property such as java.lang.Integer.IntegerCache.high which is not publicly supported but rather intended to be used as an internal conduit.

Brian

--- WITH Patch ---

$ java -Xint -Djava.lang.Integer.IntegerCache.high=888888888888888888888888888 GoodbyeWorld
 Goodbye Cruel World! 

$ java -Xint -Djava.lang.Integer.IntegerCache.high=1024\-Xmx2g GoodbyeWorld
 Goodbye Cruel World! 

$ java -Xint -XX:AutoBoxCacheMax=888888888888888888888888888 GoodbyeWorld
 Goodbye Cruel World! 

$ java -Xint -XX:AutoBoxCacheMax=1024\-Xmx2g GoodbyeWorld
Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

--- WITHOUT Patch ---

$ java -Xint -Djava.lang.Integer.IntegerCache.high=888888888888888888888888888 GoodbyeWorld
Error occurred during initialization of VM
java.lang.ExceptionInInitializerError
	at java.lang.Integer.valueOf(Integer.java:826)
	at sun.misc.Signal.handle(Signal.java:169)
	at java.lang.Terminator.setup(Terminator.java:60)
	at java.lang.System.initializeSystemClass(System.java:1192)
Caused by: java.lang.NumberFormatException: For input string: "888888888888888888888888888"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:583)
	at java.lang.Integer.parseInt(Integer.java:615)
	at java.lang.Integer$IntegerCache.(Integer.java:791)
	at java.lang.Integer.valueOf(Integer.java:826)
	at sun.misc.Signal.handle(Signal.java:169)
	at java.lang.Terminator.setup(Terminator.java:60)
	at java.lang.System.initializeSystemClass(System.java:1192)

$ java -Xint -Djava.lang.Integer.IntegerCache.high=1024\-Xmx2g GoodbyeWorld
Error occurred during initialization of VM
java.lang.ExceptionInInitializerError
	at java.lang.Integer.valueOf(Integer.java:826)
	at sun.misc.Signal.handle(Signal.java:169)
	at java.lang.Terminator.setup(Terminator.java:60)
	at java.lang.System.initializeSystemClass(System.java:1192)
Caused by: java.lang.NumberFormatException: For input string: "1024-Xmx2g"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.lang.Integer.parseInt(Integer.java:580)
	at java.lang.Integer.parseInt(Integer.java:615)
	at java.lang.Integer$IntegerCache.(Integer.java:791)
	at java.lang.Integer.valueOf(Integer.java:826)
	at sun.misc.Signal.handle(Signal.java:169)
	at java.lang.Terminator.setup(Terminator.java:60)
	at java.lang.System.initializeSystemClass(System.java:1192)

$ java -Xint -XX:AutoBoxCacheMax=888888888888888888888888888 GoodbyeWorld
 Goodbye Cruel World!

$ java -Xint -XX:AutoBoxCacheMax=1024\-Xmx2g GoodbyeWorldImproperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g'
Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.




From amy.lu at oracle.com  Thu Jun 13 01:04:37 2013
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 13 Jun 2013 09:04:37 +0800
Subject: Code Review Request: More tests for 7184826: (reflect) Add support
	for Project Lambda concepts in core reflection
In-Reply-To: <519E2C52.20203@oracle.com>
References: <519E2C52.20203@oracle.com>
Message-ID: <51B91AA5.6090807@oracle.com>

This has been pending on review for long ... Please help to review. I 
also need a sponsor for this.

Thank you very much.

/Amy

On 5/23/13 10:48 PM, Amy Lu wrote:
> Please help to review:
>
> More tests for 7184826: (reflect) Add support for Project Lambda 
> concepts in core reflection
>
> This includes:
> 1. improvement for existing tests with more situations
> 2. Test for invoking interface default/static method by j.l.r.Method
> 3. Test for invoking interface default/static method by MethodHandle
>
> https://dl.dropboxusercontent.com/u/5812451/yl153753/7184826/webrev.00/index.html 
>
>
> Thanks,
> Amy



From weijun.wang at oracle.com  Thu Jun 13 02:01:22 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Thu, 13 Jun 2013 02:01:22 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130613020145.D5A6F481A7@hg.openjdk.java.net>

Changeset: 021fdd093cd9
Author:    weijun
Date:      2013-06-13 09:59 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/021fdd093cd9

8014310: JAAS/Krb5LoginModule using des encytypes failure with NPE after JDK-8012679
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/OneKDC.java
+ test/sun/security/krb5/auto/OnlyDesLogin.java

Changeset: e9c5ad10fa4b
Author:    weijun
Date:      2013-06-13 10:00 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9c5ad10fa4b

8015274: TEST_BUG: Step2: After selecting 'View Warning Log', it is empty instead of FileNotFound.
8015276: TEST_BUG: The 'ptool.test' can't be saved in the 'tmp' folder.
8016158: Instruction is not clear on how to use keytool to create JKS store in case
Reviewed-by: mullan

! test/sun/security/tools/policytool/Alias.sh
! test/sun/security/tools/policytool/ChangeUI.html
! test/sun/security/tools/policytool/ChangeUI.sh
! test/sun/security/tools/policytool/OpenPolicy.sh
! test/sun/security/tools/policytool/SaveAs.sh
! test/sun/security/tools/policytool/UpdatePermissions.html
! test/sun/security/tools/policytool/UpdatePermissions.sh
! test/sun/security/tools/policytool/UsePolicy.sh
! test/sun/security/tools/policytool/i18n.html
! test/sun/security/tools/policytool/i18n.sh



From david.holmes at oracle.com  Thu Jun 13 02:55:37 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Jun 2013 19:55:37 -0700 (PDT)
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: 
References: <51B7896A.70109@oracle.com>
	
Message-ID: <51B934A9.8000103@oracle.com>

Something of an aside but ...

On 13/06/2013 3:45 AM, Martin Buchholz wrote:
> Hi Brent,
>
> Thanks for doing this.
>
> Your webrev does not include mercurial changeset information, which I think
> is supported by recent webrevs.

Given the changeset has to be created after the review is complete 
most/many people will not have a changeset prepared at review time. The 
webrev support for changesets IIRC was for a specific group of people 
with a specific working style (using mq) that was much more convenient 
when webrevs had changesets rather than just patches.

David
-----

> I assume you've been working with Doug Lea on this.  If not, the two of you
> should talk.
>
> BTW, it's sad not to see things like murmur hash be public supported
> algorithms - but I think guava provides it.
>
>
> On Tue, Jun 11, 2013 at 1:32 PM, Brent Christian > wrote:
>
>> Hi,
>>
>> Please review my fix for 8010325.  Some background:
>>
>> The alternative string-hashing implementation[1] added to java.lang.String
>> a new public method, hash32(), as well as a new private int field to cache
>> the alternate hash value.
>>
>> Following 8005698 [2] and 8005704 [3], the new method and field in String
>> are no longer used.
>>
>> By updating a couple lines in Hashtable/HashMap/WeakHashMap, the internal
>> sun.misc.Hashing class can also be removed.
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~**bchristi/8010325/webrev.00/
>>
>> Thanks,
>> -Brent
>>
>> 1. http://hg.openjdk.java.net/**jdk8/jdk8/jdk/rev/43bd5ee0205e
>> 2. http://bugs.sun.com/view_bug.**do?bug_id=8005698
>> 3. http://bugs.sun.com/view_bug.**do?bug_id=8005704
>>


From mandy.chung at oracle.com  Thu Jun 13 04:47:12 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 12 Jun 2013 21:47:12 -0700
Subject: Review request JDK-8015912: jdeps support to output in dot file
	format
In-Reply-To: <27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com>
References: <51B68F95.9060109@oracle.com>
	<27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com>
Message-ID: <51B94ED0.3010505@oracle.com>

Alan, Paul,

Thanks for the review.  Here is the revised webrev:
   http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.01

See my comments inlined below.

On 6/12/2013 3:48 AM, Paul Sandoz wrote:
> Hi Mandy,
>
> JdepsTask:
>
> Given that the dot graph output is likely to be just as human readable as your original format it is very tempting just to support that format. In fact it is likely to be more human readable since the output is of a known syntax. So IMHO we don't need a format option and dot graph output is sufficient.

The package names and classnames in the dot graph output are 
double-quote strings or the '.'  character has to be escaped.  I think 
it's more of a noise as the default output.

>
>   636             log.format("digraph G {%n");
>
> Perhaps a better name can be chosen for the title of the summary graph?

Oh yes - I change it to "jdeps summary".  Is it any better?
>
> You don't need to pass in the log PrintWriter to the OutputWriter implementations if they are non-static i.e. sometimes you use "out" and sometimes you use "log".

I agree.  Fixed.
>
> PlatformClassPath:
>
>    53     static boolean contains(Archive archive) {
>    54         return javaHomeArchives.contains(archive) && !archive.getFileName().equals("jfxrt.jar");
>    55     }
>
> Just curious: why is the the check for "jfxrt.jar" required?

If jfxrt.jar is bundled with JRE, it's in the jre/lib/ext directory but 
it's not part of the JRE and not in any profile.  Thus it should be 
filtered out.

>
> Profiles:
>
> You might be able to use a lambda expression when creating the comparator for the TreeSet:
>
>    Set profiles = new TreeSet((p1, p2) -> { ... });
>
> I realize that is just for debugging so it's not really important, but i have lambda goggles on so cannot help it :-)

Yup it would be nice but langtools is built with the boot jdk.

Mandy
>
> Paul.
>
> On Jun 11, 2013, at 4:46 AM, Mandy Chung  wrote:
>
>> This adds jdeps --format=dot option to print the output in dot-style format that can be taken to generate a dependency graph.
>>
>> Webrev at:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.00/
>>
>> This also extends --verbose option to take an optional argument ("class" and "package") to replace the --verbose-level option and cleans up PlatformClassPath to use java.nio.file.
>>
>> thanks
>> Mandy



From mike.duigou at oracle.com  Thu Jun 13 05:28:53 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 12 Jun 2013 22:28:53 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B8FB12.2090901@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
Message-ID: <081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>

I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.

Revised webrev:

http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/

Mike


On Jun 12 2013, at 15:49 , Remi Forax wrote:

> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>> Hello all;
>> 
>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>> 
>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>> 
>> Mike
> 
> Hi Mike,
> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
> 
> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
> and does the modCount check for each element because a call to the consumer can change the underlying map
> so you can not do a modCount check only at the end.
> 
> R?mi
> 
> Here is the diff.
> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
> @@ -28,6 +28,7 @@
> import java.io.*;
> import java.lang.reflect.ParameterizedType;
> import java.lang.reflect.Type;
> +import java.util.function.BiConsumer;
> import java.util.function.Consumer;
> import java.util.function.BiFunction;
> import java.util.function.Function;
> @@ -2615,6 +2616,54 @@
>     int   capacity()     { return table.length; }
>     float loadFactor()   { return loadFactor;   }
> 
> +
> +    @Override
> +    public void forEach(BiConsumer action) {
> +        Objects.requireNonNull(action);
> +        final int expectedModCount = modCount;
> +        if (nullKeyEntry != null) {
> +            forEachNullKey(expectedModCount, action);
> +        }
> +        Object[] table = this.table;
> +        for(int index = 0; index < table.length; index++) {
> +            Object item = table[index];
> +            if (item == null) {
> +                continue;
> +            }
> +            if (item instanceof HashMap.TreeBin) {
> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
> +                continue;
> +            }
> +            @SuppressWarnings("unchecked")
> +            Entry entry = (Entry)item;
> +            for (;entry != null; entry = (Entry)entry.next) {
> +                if (expectedModCount != modCount) {
> +                    throw new ConcurrentModificationException();
> +                }
> +                action.accept(entry.key, entry.value);
> +            }
> +        }
> +    }
> +
> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
> +        while (node != null) {
> +            if (expectedModCount != modCount) {
> +                throw new ConcurrentModificationException();
> +            }
> +            @SuppressWarnings("unchecked")
> +            Entry entry = (Entry)node.entry;
> +            action.accept(entry.key, entry.value);
> +            node = (TreeNode)entry.next;
> +        }
> +    }
> +
> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
> +        if (expectedModCount != modCount) {
> +            throw new ConcurrentModificationException();
> +        }
> +        action.accept(null, nullKeyEntry.value);
> +    }
> +
>     /**
>      * Standin until HM overhaul; based loosely on Weak and Identity HM.
>      */
> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
> @@ -24,7 +24,8 @@
>  */
> 
> package java.util;
> -import java.io.*;
> +
> +import java.util.function.BiConsumer;
> 
> /**
>  * 
    Hash table and linked list implementation of the Map interface,
> @@ -470,4 +471,16 @@
>     protected boolean removeEldestEntry(Map.Entry eldest) {
>         return false;
>     }
> +
> +    @Override
> +    public void forEach(BiConsumer action) {
> +        Objects.requireNonNull(action);
> +        int expectedModCount = modCount;
> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
> +            if (expectedModCount != modCount) {
> +                throw new ConcurrentModificationException();
> +            }
> +            action.accept(entry.key, entry.value);
> +        }
> +    }
> }
> 
> 



From peter.levart at gmail.com  Thu Jun 13 06:42:43 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 13 Jun 2013 08:42:43 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
Message-ID: <51B969E3.6040109@gmail.com>

On 06/13/2013 01:14 AM, Mike Duigou wrote:
> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>
>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>
>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>
>>> Mike
>> Hi Mike,
>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.

The javadoc for Map.forEach says differently:

default void forEach(BiConsumer  ,? superV  > action)

Performs the given action on each entry in this map, in the order 
entries are returned by an entry set iterator (which may be unspecified)


Regards, Peter

>
>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
> Yes, this is probably worthwhile
>
>> and does the modCount check for each element because a call to the consumer can change the underlying map
>> so you can not do a modCount check only at the end.
> Yes, mine wasn't fast fail enough. I am always torn between satisfying those who will moan at the per-element cost and those who will moan about the lack of fast-fail behaviour.
>
> Thank you for the improvements!
>
> Mike



From paul.sandoz at oracle.com  Thu Jun 13 07:42:42 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 09:42:42 +0200
Subject: Review request JDK-8015912: jdeps support to output in dot file
	format
In-Reply-To: <51B94ED0.3010505@oracle.com>
References: <51B68F95.9060109@oracle.com>
	<27DBF99D-D152-4A40-BC5B-CAD79DBF00C8@oracle.com>
	<51B94ED0.3010505@oracle.com>
Message-ID: 


On Jun 13, 2013, at 6:47 AM, Mandy Chung  wrote:

> Alan, Paul,
> 
> Thanks for the review.  Here is the revised webrev:
>  http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8015912/webrev.01
> 

Looks OK.


> See my comments inlined below.
> 
> On 6/12/2013 3:48 AM, Paul Sandoz wrote:
>> Hi Mandy,
>> 
>> JdepsTask:
>> 
>> Given that the dot graph output is likely to be just as human readable as your original format it is very tempting just to support that format. In fact it is likely to be more human readable since the output is of a known syntax. So IMHO we don't need a format option and dot graph output is sufficient.
> 
> The package names and classnames in the dot graph output are double-quote strings or the '.'  character has to be escaped.  I think it's more of a noise as the default output.

I am not really convinced the quoting is noisy, i think having two formats is noise :-)

It is still very readable:

digraph "a.jar" {
  "x.y.z.Foo" -> "a.b.c.Bar";
  ....
}

Also, did you also consider using subgraph for multiple archives?


> 
>> 
>>  636             log.format("digraph G {%n");
>> 
>> Perhaps a better name can be chosen for the title of the summary graph?
> 
> Oh yes - I change it to "jdeps summary".  Is it any better?
>> 

Yes.


>> You don't need to pass in the log PrintWriter to the OutputWriter implementations if they are non-static i.e. sometimes you use "out" and sometimes you use "log".
> 
> I agree.  Fixed.
>> 
>> PlatformClassPath:
>> 
>>   53     static boolean contains(Archive archive) {
>>   54         return javaHomeArchives.contains(archive) && !archive.getFileName().equals("jfxrt.jar");
>>   55     }
>> 
>> Just curious: why is the the check for "jfxrt.jar" required?
> 
> If jfxrt.jar is bundled with JRE, it's in the jre/lib/ext directory but it's not part of the JRE and not in any profile.  Thus it should be filtered out.
> 

An outlier! Can other stuff get placed in that dir?

Paul.

From paul.sandoz at oracle.com  Thu Jun 13 07:51:17 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 09:51:17 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
Message-ID: 


On Jun 13, 2013, at 7:28 AM, Mike Duigou  wrote:

> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
> 
> Revised webrev:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
> 

The approach we have taken for bulk traversal of fail-fast spliterators and ArrayList/Vector is to check the mod count at the end of the loop. I think we should be consistent with those.

Paul.

From paul.sandoz at oracle.com  Thu Jun 13 07:56:26 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 09:56:26 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B969E3.6040109@gmail.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
	<51B969E3.6040109@gmail.com>
Message-ID: <99ED5C0E-BDFF-4518-A54A-EB602D3EF0BD@oracle.com>


On Jun 13, 2013, at 8:42 AM, Peter Levart  wrote:

> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>> 
>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>> Hello all;
>>>> 
>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>> 
>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>> 
>>>> Mike
>>> Hi Mike,
>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
> 
> The javadoc for Map.forEach says differently:
> 
> default void forEach(BiConsumer  ,? superV  > action)
> 
> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)

Right, LinkedHashMap should preserve the encounter order on traversal, bulk or otherwise.

Note that there is a bug logged against LinkedHashMap.spliterator. It should but currently does not report ORDERED for key/value/entry Spliterators.

Paul.

From paul.sandoz at oracle.com  Thu Jun 13 08:03:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 10:03:05 +0200
Subject: RFR: 8016448: java/util/BitSet/BitSetStreamTest.java no longer
	compiles, missed by 8015895
In-Reply-To: <51B8DE86.1060002@oracle.com>
References: <51B8DE86.1060002@oracle.com>
Message-ID: <263A54A2-05B9-4B27-846E-856724CBC5F1@oracle.com>


On Jun 12, 2013, at 10:48 PM, Henry Jen  wrote:

> Hi,
> 
> Please review a simple fix for 8016448, a test case missed from a API
> change commit.
> 
> http://cr.openjdk.java.net/~henryjen/tl/8016448.0/webrev/
> 

Ooops that's my fault. Thanks for noticing this.

I thought i checked with a JPRT run, but my patch queue might not have been fully applied, or i missed the failure in the noise of other non-realted failures.

Paul.



From forax at univ-mlv.fr  Thu Jun 13 08:15:55 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 10:15:55 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
Message-ID: <51B97FBB.8020706@univ-mlv.fr>

On 06/13/2013 09:51 AM, Paul Sandoz wrote:
> On Jun 13, 2013, at 7:28 AM, Mike Duigou  wrote:
>
>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>
>> Revised webrev:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>
> The approach we have taken for bulk traversal of fail-fast spliterators and ArrayList/Vector is to check the mod count at the end of the loop. I think we should be consistent with those.
>
> Paul.

Hi Paul,
ArrayList.forEach() does the modCount check at each step.
There is a difference between an Iterator/forEach and a spliterator/stream,
with a stream you know that the called lambdas will not interfere and 
mutate the source collection.

R?mi



From yong.huang at oracle.com  Thu Jun 13 08:41:56 2013
From: yong.huang at oracle.com (yong.huang at oracle.com)
Date: Thu, 13 Jun 2013 08:41:56 +0000
Subject: hg: jdk8/tl/jdk: 7040556: SimpleDateFormat.format Portuguese Month
	should not be capitalized
Message-ID: <20130613084226.2763B481B8@hg.openjdk.java.net>

Changeset: 3c7bab68cd2f
Author:    yhuang
Date:      2013-06-12 23:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c7bab68cd2f

7040556: SimpleDateFormat.format Portuguese Month should not be capitalized
Reviewed-by: okutsu

! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java



From paul.sandoz at oracle.com  Thu Jun 13 08:44:54 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 10:44:54 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B97FBB.8020706@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
Message-ID: <3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>

On Jun 13, 2013, at 10:15 AM, Remi Forax  wrote:
> On 06/13/2013 09:51 AM, Paul Sandoz wrote:
>> On Jun 13, 2013, at 7:28 AM, Mike Duigou  wrote:
>> 
>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>> 
>>> Revised webrev:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>> 
>> The approach we have taken for bulk traversal of fail-fast spliterators and ArrayList/Vector is to check the mod count at the end of the loop. I think we should be consistent with those.
>> 
>> Paul.
> 
> Hi Paul,
> ArrayList.forEach() does the modCount check at each step.

Doh, yes, i mis read the logic in the for statement in ArrayList/Vector.


> There is a difference between an Iterator/forEach and a spliterator/stream,
> with a stream you know that the called lambdas will not interfere and mutate the source collection.
> 

You do? I don't think there is any conceptual difference between the following w.r.t. interference:

  ArrayList l = ...
  l.stream().filter(...).forEach(e -> l.add(e));
  l.spliterator().forEachRemaining(e -> l.add(e));

and:

  ArrayList l = ...
  l.forEach(e -> l.add(e));
  l.iterator().forEachRemaining(e -> l.add(e));

Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.

So we are still inconsistent between Spliterator.forEachRemaining and Iterator.forEachReamining/Collection.forEach.

Paul.

From paul.sandoz at oracle.com  Thu Jun 13 09:22:30 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 13 Jun 2013 09:22:30 +0000
Subject: hg: jdk8/tl/jdk: 8016251: Balanced spliterator for SpinedBuffer
Message-ID: <20130613092254.2F30E481BA@hg.openjdk.java.net>

Changeset: a50394c44464
Author:    psandoz
Date:      2013-06-13 11:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50394c44464

8016251: Balanced spliterator for SpinedBuffer
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Peter Levart , Paul Sandoz 

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java



From chris.hegarty at oracle.com  Thu Jun 13 09:30:52 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 13 Jun 2013 10:30:52 +0100
Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
In-Reply-To: <51B89CB0.3080503@oracle.com>
References: <51B88AA1.4090701@oracle.com> <51B89CB0.3080503@oracle.com>
Message-ID: <51B9914C.8060102@oracle.com>

On 06/12/2013 05:07 PM, Alan Bateman wrote:
> On 12/06/2013 15:50, Chris Hegarty wrote:
>> ...
> Is the name final? Just curious if other names such as parallelScan have
> been considered (and discarded).

I think we should be open to discussing the name, but I will have to 
defer to Doug as to whether other names were considered/discarded.

It seems the convention we are adopting for naming these new methods, 
whose implementation is parallelized, is to prefix the name with 
'parallel' ( parallelSort, parallelSetAll ). Sounds fine. Otherwise I 
would have preferred something like prefixScan(..).

Options so far:

   parallelPrefix(..)  // what we have today
   parallelScan(..)
   parallelPrefixScan(..)   // too long winded??

> "Cumulates in parallel each element ...", I guess I would put a comma
> before and after "in parallel".

Yes, I will add this.

> Otherwise the API looks good to me.

Thanks Alan,
-Chris.

>
> -Alan.
>
>
>


From ivan.gerasimov at oracle.com  Thu Jun 13 10:33:56 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 13 Jun 2013 14:33:56 +0400
Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails
	intermittently
In-Reply-To: <51B8443A.7000801@oracle.com>
References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com>
	<51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com>
	<51B73090.5010407@oracle.com> <51B8443A.7000801@oracle.com>
Message-ID: <51B9A014.2000401@oracle.com>

Thank you, David.

I've reverted the code back, added volatile specification to the count 
variable.
Would you please review the webrev with this only change (comparing to 
webrev.0):
http://cr.openjdk.java.net/~igerasim/7181748/webrev.2/

Sincerely yours,
Ivan

On 12.06.2013 13:49, David Holmes wrote:
> On 12/06/2013 12:13 AM, Ivan Gerasimov wrote:
>> Chris and David, thanks for review.
>>
>> I've updated the test so the threads use CountDownLatch to wait for each
>> other.
>> Now, instead of checking whether the 'second' thread has incremented a
>> count, the 'main' thread waits for it to call countDown().
>> If a timeout was elapsed before the call, I assume that the 'second'
>> thread is suspended and the test passes.
>
> I do not advise doing this. The second thread can be suspended inside 
> the CountdownLatch code. When suspend is involved you do not want any 
> direct interaction between the main thread and the thread being 
> suspended.
>
> David
> -----
>
>> Could you please review the updated webrev:
>> http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/
>>
>> Sincerely,
>> Ivan
>>
>> On 11.06.2013 13:37, Chris Hegarty wrote:
>>> On 06/11/2013 08:08 AM, David Holmes wrote:
>>>> On 11/06/2013 1:54 AM, Chris Hegarty wrote:
>>>>> I'm not sure I ever saw this test fail, but it does look like it has
>>>>> issues.
>>>>>
>>>>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
>>>>> across these threads.
>>>>
>>>> I don't think that is possible. The main thread wants to reset the 
>>>> count
>>>> after the suspend has been issued by "first", but once the suspend has
>>>> been issued the "first" thread can't signal the synchronizer to let 
>>>> the
>>>> main thread proceed. The poll around isAlive() does address the main
>>>> issue of a slowly starting thread.
>>>
>>> Ah yes, thanks David. In which case I'm fine with the change.
>>>
>>>> For completeness the count variable should be volatile as well.
>>>
>>> Agreed.
>>>
>>> -Chris.
>>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> -Chris.
>>>>>
>>>>> On 10/06/2013 13:51, Ivan Gerasimov wrote:
>>>>>> Hello everyone!
>>>>>>
>>>>>> The test of ThreadGroup.Suspend() was reported to fail on rare
>>>>>> occasions.
>>>>>> It can happen on a busy machine that 1 second delay would not be
>>>>>> enough
>>>>>> for the second thread to start.
>>>>>> Then the first thread would suspend only itself and the test would
>>>>>> fail.
>>>>>> Earlier, another test was updated for similar reasons [1], [2].
>>>>>>
>>>>>> The proposed test can still report false *positive* results if the
>>>>>> second thread has had no chance to execute during one second 
>>>>>> after it
>>>>>> had started.
>>>>>> To avoid them there must be a way do distinguish suspended threads.
>>>>>>
>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/
>>>>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748
>>>>>>
>>>>>>
>>>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033
>>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan Gerasimov
>>>>>> 
>>>
>>>
>>
>
>



From chris.hegarty at oracle.com  Thu Jun 13 10:35:59 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 13 Jun 2013 11:35:59 +0100
Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails
	intermittently
In-Reply-To: <51B9A014.2000401@oracle.com>
References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com>
	<51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com>
	<51B73090.5010407@oracle.com> <51B8443A.7000801@oracle.com>
	<51B9A014.2000401@oracle.com>
Message-ID: <51B9A08F.3080108@oracle.com>

The updated webrev looks good to me Ivan. Sorry for sending you off on 
the wrong track!

Let me know if you need a sponsor to push this.

-Chris.

On 06/13/2013 11:33 AM, Ivan Gerasimov wrote:
> Thank you, David.
>
> I've reverted the code back, added volatile specification to the count
> variable.
> Would you please review the webrev with this only change (comparing to
> webrev.0):
> http://cr.openjdk.java.net/~igerasim/7181748/webrev.2/
>
> Sincerely yours,
> Ivan
>
> On 12.06.2013 13:49, David Holmes wrote:
>> On 12/06/2013 12:13 AM, Ivan Gerasimov wrote:
>>> Chris and David, thanks for review.
>>>
>>> I've updated the test so the threads use CountDownLatch to wait for each
>>> other.
>>> Now, instead of checking whether the 'second' thread has incremented a
>>> count, the 'main' thread waits for it to call countDown().
>>> If a timeout was elapsed before the call, I assume that the 'second'
>>> thread is suspended and the test passes.
>>
>> I do not advise doing this. The second thread can be suspended inside
>> the CountdownLatch code. When suspend is involved you do not want any
>> direct interaction between the main thread and the thread being
>> suspended.
>>
>> David
>> -----
>>
>>> Could you please review the updated webrev:
>>> http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/
>>>
>>> Sincerely,
>>> Ivan
>>>
>>> On 11.06.2013 13:37, Chris Hegarty wrote:
>>>> On 06/11/2013 08:08 AM, David Holmes wrote:
>>>>> On 11/06/2013 1:54 AM, Chris Hegarty wrote:
>>>>>> I'm not sure I ever saw this test fail, but it does look like it has
>>>>>> issues.
>>>>>>
>>>>>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
>>>>>> across these threads.
>>>>>
>>>>> I don't think that is possible. The main thread wants to reset the
>>>>> count
>>>>> after the suspend has been issued by "first", but once the suspend has
>>>>> been issued the "first" thread can't signal the synchronizer to let
>>>>> the
>>>>> main thread proceed. The poll around isAlive() does address the main
>>>>> issue of a slowly starting thread.
>>>>
>>>> Ah yes, thanks David. In which case I'm fine with the change.
>>>>
>>>>> For completeness the count variable should be volatile as well.
>>>>
>>>> Agreed.
>>>>
>>>> -Chris.
>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 10/06/2013 13:51, Ivan Gerasimov wrote:
>>>>>>> Hello everyone!
>>>>>>>
>>>>>>> The test of ThreadGroup.Suspend() was reported to fail on rare
>>>>>>> occasions.
>>>>>>> It can happen on a busy machine that 1 second delay would not be
>>>>>>> enough
>>>>>>> for the second thread to start.
>>>>>>> Then the first thread would suspend only itself and the test would
>>>>>>> fail.
>>>>>>> Earlier, another test was updated for similar reasons [1], [2].
>>>>>>>
>>>>>>> The proposed test can still report false *positive* results if the
>>>>>>> second thread has had no chance to execute during one second
>>>>>>> after it
>>>>>>> had started.
>>>>>>> To avoid them there must be a way do distinguish suspended threads.
>>>>>>>
>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/
>>>>>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748
>>>>>>>
>>>>>>>
>>>>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033
>>>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan Gerasimov
>>>>>>> 
>>>>
>>>>
>>>
>>
>>
>


From Alan.Bateman at oracle.com  Thu Jun 13 10:42:29 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Jun 2013 11:42:29 +0100
Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
In-Reply-To: <51B9914C.8060102@oracle.com>
References: <51B88AA1.4090701@oracle.com> <51B89CB0.3080503@oracle.com>
	<51B9914C.8060102@oracle.com>
Message-ID: <51B9A215.70002@oracle.com>

On 13/06/2013 10:30, Chris Hegarty wrote:
> On 06/12/2013 05:07 PM, Alan Bateman wrote:
>> On 12/06/2013 15:50, Chris Hegarty wrote:
>>> ...
>> Is the name final? Just curious if other names such as parallelScan have
>> been considered (and discarded).
>
> I think we should be open to discussing the name, but I will have to 
> defer to Doug as to whether other names were considered/discarded.
>
BTW: I was looking to re-open an existing decision, rather it was just a 
first reaction to "prefix" that made me think "prefix sum".

-Alan



From david.holmes at oracle.com  Thu Jun 13 10:54:28 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 13 Jun 2013 20:54:28 +1000
Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails
	intermittently
In-Reply-To: <51B9A014.2000401@oracle.com>
References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com>
	<51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com>
	<51B73090.5010407@oracle.com> <51B8443A.7000801@oracle.com>
	<51B9A014.2000401@oracle.com>
Message-ID: <51B9A4E4.8090107@oracle.com>

Thumbs up from me.

These tests can never be perfect, but this addresses the problem that 
was being observed. Of course now it might just shift the problem ...

David

On 13/06/2013 8:33 PM, Ivan Gerasimov wrote:
> Thank you, David.
>
> I've reverted the code back, added volatile specification to the count
> variable.
> Would you please review the webrev with this only change (comparing to
> webrev.0):
> http://cr.openjdk.java.net/~igerasim/7181748/webrev.2/
>
> Sincerely yours,
> Ivan
>
> On 12.06.2013 13:49, David Holmes wrote:
>> On 12/06/2013 12:13 AM, Ivan Gerasimov wrote:
>>> Chris and David, thanks for review.
>>>
>>> I've updated the test so the threads use CountDownLatch to wait for each
>>> other.
>>> Now, instead of checking whether the 'second' thread has incremented a
>>> count, the 'main' thread waits for it to call countDown().
>>> If a timeout was elapsed before the call, I assume that the 'second'
>>> thread is suspended and the test passes.
>>
>> I do not advise doing this. The second thread can be suspended inside
>> the CountdownLatch code. When suspend is involved you do not want any
>> direct interaction between the main thread and the thread being
>> suspended.
>>
>> David
>> -----
>>
>>> Could you please review the updated webrev:
>>> http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/
>>>
>>> Sincerely,
>>> Ivan
>>>
>>> On 11.06.2013 13:37, Chris Hegarty wrote:
>>>> On 06/11/2013 08:08 AM, David Holmes wrote:
>>>>> On 11/06/2013 1:54 AM, Chris Hegarty wrote:
>>>>>> I'm not sure I ever saw this test fail, but it does look like it has
>>>>>> issues.
>>>>>>
>>>>>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
>>>>>> across these threads.
>>>>>
>>>>> I don't think that is possible. The main thread wants to reset the
>>>>> count
>>>>> after the suspend has been issued by "first", but once the suspend has
>>>>> been issued the "first" thread can't signal the synchronizer to let
>>>>> the
>>>>> main thread proceed. The poll around isAlive() does address the main
>>>>> issue of a slowly starting thread.
>>>>
>>>> Ah yes, thanks David. In which case I'm fine with the change.
>>>>
>>>>> For completeness the count variable should be volatile as well.
>>>>
>>>> Agreed.
>>>>
>>>> -Chris.
>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>> On 10/06/2013 13:51, Ivan Gerasimov wrote:
>>>>>>> Hello everyone!
>>>>>>>
>>>>>>> The test of ThreadGroup.Suspend() was reported to fail on rare
>>>>>>> occasions.
>>>>>>> It can happen on a busy machine that 1 second delay would not be
>>>>>>> enough
>>>>>>> for the second thread to start.
>>>>>>> Then the first thread would suspend only itself and the test would
>>>>>>> fail.
>>>>>>> Earlier, another test was updated for similar reasons [1], [2].
>>>>>>>
>>>>>>> The proposed test can still report false *positive* results if the
>>>>>>> second thread has had no chance to execute during one second
>>>>>>> after it
>>>>>>> had started.
>>>>>>> To avoid them there must be a way do distinguish suspended threads.
>>>>>>>
>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/
>>>>>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748
>>>>>>>
>>>>>>>
>>>>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033
>>>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan Gerasimov
>>>>>>> 
>>>>
>>>>
>>>
>>
>>
>


From Alan.Bateman at oracle.com  Thu Jun 13 11:09:47 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 13 Jun 2013 12:09:47 +0100
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: <51B8EECD.3090509@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B8A226.8010205@oracle.com> <51B8E430.2000200@oracle.com>
	<51B8EECD.3090509@oracle.com>
Message-ID: <51B9A87B.6030402@oracle.com>

On 12/06/2013 22:57, Brent Christian wrote:
> Hi, Se?n
>
> I admit that I did not think to update FILES_java.gmk.  A quick 
> informal poll indicates that the old build is already broken on jdk8, 
> and has been for some time.

There has been discussion on build-dev recently about setting a date, 
after which it is fair game to remove the old make files.

As regards whether the old build is already broken then I think that is 
true. When the streams API was added then it didn't update the old build 
with the result that not all of java.util.stream is in rt.jar when you 
use old build. There are a few other specific cases where things are 
missing if you use the old build. I'm also pretty sure that Nashorn is 
missing too. So overall I would say that the resulting bits from the old 
build are currently incomplete and should not be used. At least in 
Oracle, then we officially switched to the new build months ago and 
there is no testing of bits from the old build.

-Alan.


From ivan.gerasimov at oracle.com  Thu Jun 13 11:24:00 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 13 Jun 2013 15:24:00 +0400
Subject: RFR [7181748] TEST_BUG: java/lang/ThreadGroup/Suspend test fails
	intermittently
In-Reply-To: <51B9A08F.3080108@oracle.com>
References: <51B5CBD5.8040406@oracle.com> <51B5F6BF.6060704@oracle.com>
	<51B6CCE5.4050402@oracle.com> <51B6EFE9.9080104@oracle.com>
	<51B73090.5010407@oracle.com> <51B8443A.7000801@oracle.com>
	<51B9A014.2000401@oracle.com> <51B9A08F.3080108@oracle.com>
Message-ID: <51B9ABD0.1000602@oracle.com>

Thank you Chris, I would really appreciate your sponsor's help!

Here's the patch for this change: 
http://cr.openjdk.java.net/~igerasim/2commit/7181748-jdk8-Suspend-test-fails.patch

Sincerely yours,
Ivan

On 13.06.2013 14:35, Chris Hegarty wrote:
> The updated webrev looks good to me Ivan. Sorry for sending you off on 
> the wrong track!
>
> Let me know if you need a sponsor to push this.
>
> -Chris.
>
> On 06/13/2013 11:33 AM, Ivan Gerasimov wrote:
>> Thank you, David.
>>
>> I've reverted the code back, added volatile specification to the count
>> variable.
>> Would you please review the webrev with this only change (comparing to
>> webrev.0):
>> http://cr.openjdk.java.net/~igerasim/7181748/webrev.2/
>>
>> Sincerely yours,
>> Ivan
>>
>> On 12.06.2013 13:49, David Holmes wrote:
>>> On 12/06/2013 12:13 AM, Ivan Gerasimov wrote:
>>>> Chris and David, thanks for review.
>>>>
>>>> I've updated the test so the threads use CountDownLatch to wait for 
>>>> each
>>>> other.
>>>> Now, instead of checking whether the 'second' thread has incremented a
>>>> count, the 'main' thread waits for it to call countDown().
>>>> If a timeout was elapsed before the call, I assume that the 'second'
>>>> thread is suspended and the test passes.
>>>
>>> I do not advise doing this. The second thread can be suspended inside
>>> the CountdownLatch code. When suspend is involved you do not want any
>>> direct interaction between the main thread and the thread being
>>> suspended.
>>>
>>> David
>>> -----
>>>
>>>> Could you please review the updated webrev:
>>>> http://cr.openjdk.java.net/~igerasim/7181748/webrev.1/
>>>>
>>>> Sincerely,
>>>> Ivan
>>>>
>>>> On 11.06.2013 13:37, Chris Hegarty wrote:
>>>>> On 06/11/2013 08:08 AM, David Holmes wrote:
>>>>>> On 11/06/2013 1:54 AM, Chris Hegarty wrote:
>>>>>>> I'm not sure I ever saw this test fail, but it does look like it 
>>>>>>> has
>>>>>>> issues.
>>>>>>>
>>>>>>> I would much prefer to see a j.u.c.Latch/Phaser used to synchronize
>>>>>>> across these threads.
>>>>>>
>>>>>> I don't think that is possible. The main thread wants to reset the
>>>>>> count
>>>>>> after the suspend has been issued by "first", but once the 
>>>>>> suspend has
>>>>>> been issued the "first" thread can't signal the synchronizer to let
>>>>>> the
>>>>>> main thread proceed. The poll around isAlive() does address the main
>>>>>> issue of a slowly starting thread.
>>>>>
>>>>> Ah yes, thanks David. In which case I'm fine with the change.
>>>>>
>>>>>> For completeness the count variable should be volatile as well.
>>>>>
>>>>> Agreed.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>> On 10/06/2013 13:51, Ivan Gerasimov wrote:
>>>>>>>> Hello everyone!
>>>>>>>>
>>>>>>>> The test of ThreadGroup.Suspend() was reported to fail on rare
>>>>>>>> occasions.
>>>>>>>> It can happen on a busy machine that 1 second delay would not be
>>>>>>>> enough
>>>>>>>> for the second thread to start.
>>>>>>>> Then the first thread would suspend only itself and the test would
>>>>>>>> fail.
>>>>>>>> Earlier, another test was updated for similar reasons [1], [2].
>>>>>>>>
>>>>>>>> The proposed test can still report false *positive* results if the
>>>>>>>> second thread has had no chance to execute during one second
>>>>>>>> after it
>>>>>>>> had started.
>>>>>>>> To avoid them there must be a way do distinguish suspended 
>>>>>>>> threads.
>>>>>>>>
>>>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/7181748/webrev.0/
>>>>>>>> BUG: http://bugs.sun.com/view_bug.do?bug_id=7181748
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7084033
>>>>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/184578f3e8b9
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan Gerasimov
>>>>>>>> 
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From dl at cs.oswego.edu  Thu Jun 13 11:30:15 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 13 Jun 2013 07:30:15 -0400 (EDT)
Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
In-Reply-To: <51B9A215.70002@oracle.com>
References: <51B88AA1.4090701@oracle.com> <51B89CB0.3080503@oracle.com>
	<51B9914C.8060102@oracle.com> <51B9A215.70002@oracle.com>
Message-ID: <55124.71.248.126.170.1371123015.squirrel@altair.cs.oswego.edu>

> On 13/06/2013 10:30, Chris Hegarty wrote:
>> On 06/12/2013 05:07 PM, Alan Bateman wrote:
>>> On 12/06/2013 15:50, Chris Hegarty wrote:
>>>> ...
>>> Is the name final? Just curious if other names such as parallelScan
>>> have
>>> been considered (and discarded).
>>
>> I think we should be open to discussing the name, but I will have to
>> defer to Doug as to whether other names were considered/discarded.

Well, I originally called it "cumulate" and still like it best,
but others on expert group suggested parallelPrefix as less
likely to be confused with other methods they may be looking
for. So at this point I think we should stick with it.

-Doug





From aleksey.shipilev at oracle.com  Thu Jun 13 11:47:35 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 13 Jun 2013 15:47:35 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51B5F684.9010600@oracle.com>
References: <51B5F684.9010600@oracle.com>
Message-ID: <51B9B157.10708@oracle.com>

Friendly reminder for the reviewers.

On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
> This is the follow-up on the issue Doug identified:
>   http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
> 
> I had reworked the patch, webrev is here:
>   http://cr.openjdk.java.net/~shade/8016236/webrev.01/

The current webrev is here:
  http://cr.openjdk.java.net/~shade/8016236/webrev.02/

> Notable differences from Doug's version are:
>   - handle non-generic cases as well
>   - reuse ReflectionData to cache the interfaces
>   - code style (chained ternary operators blown up)
>   - fixes the race along the way
>       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6398355
> 
> Testing:
>   - Linux x86_64/release: build OK
>   - Linux x86_64/release: java/lang/reflect regression tests OK
>   - Microbenchmarks show whooping increase in performance, see below

Thanks,
Aleksey.



From david.r.chase at oracle.com  Thu Jun 13 12:02:58 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 13 Jun 2013 08:02:58 -0400
Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
In-Reply-To: <55124.71.248.126.170.1371123015.squirrel@altair.cs.oswego.edu>
References: <51B88AA1.4090701@oracle.com> <51B89CB0.3080503@oracle.com>
	<51B9914C.8060102@oracle.com> <51B9A215.70002@oracle.com>
	<55124.71.248.126.170.1371123015.squirrel@altair.cs.oswego.edu>
Message-ID: <5E4D8DA0-A8E5-4FFB-BEB9-5A0723CDDD9C@oracle.com>


On 2013-06-13, at 7:30 AM, Doug Lea 
     wrote:

>> On 13/06/2013 10:30, Chris Hegarty wrote:
>>> On 06/12/2013 05:07 PM, Alan Bateman wrote:
>>>> On 12/06/2013 15:50, Chris Hegarty wrote:
>>>>> ...
>>>> Is the name final? Just curious if other names such as parallelScan
>>>> have
>>>> been considered (and discarded).
>>> 
>>> I think we should be open to discussing the name, but I will have to
>>> defer to Doug as to whether other names were considered/discarded.
> 
> Well, I originally called it "cumulate" and still like it best,
> but others on expert group suggested parallelPrefix as less
> likely to be confused with other methods they may be looking
> for. So at this point I think we should stick with it.

I think it's worth discussing.  The expert group is going to be predisposed to go with the jargon that they know, not unlike habitual Lisp hackers thinking that "car", "cdr" and "cons" are perfectly natural names for operations.  This is our chance to avoid baking in clunky jargon, and I think that in a few years we'll assume all sorts of stuff is done in parallel, and methods named parallelThis and parallelThat will be anachronisms.

The one huge advantage of parallelPrefix is that if you drop it into Google, the first result delivered is the one that you want (Wikipedia on "prefix Sum").  "prefix Cumulate" also delivers that page, though with the suggestion "did you mean prefix cumulus"?  The other advantage is that we have no particular assurance that we'll invent anything better.

And matlab, numpy, R, TI Basic, and Oracle OLAP DML call it (or a specific version of it) "cumsum".  R's version of cumsum is pretty generic, and cumsum gets decent hits from Google.  "Cumsum", however, shows clear signs of 6-letter-jargon itself.

"Cumulate" by itself doesn't yield useful hits, at least not today.

David



From forax at univ-mlv.fr  Thu Jun 13 13:21:49 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 15:21:49 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
Message-ID: <51B9C76D.2040905@univ-mlv.fr>

On 06/13/2013 07:28 AM, Mike Duigou wrote:
> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>
> Revised webrev:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>
> Mike

Hi Mike,

in TreeMap.forEach (and replaceAll), the check for co-modification 
should be done *before* action.accept(...)
and not after because the semantics of the Iterator allows users to 
modify the map (hashmap or treemap)
if it's the last element (so we should not check modCount after the last 
element).
Also the code of forEach inside the loop is basically a hand-inlined 
version of Treemap.successor(),
I wonder if it's not better to use successor() here ?

in Hashtable.replaceAll(), the cast to K and V in function.apply() is 
useless.

otherwise, all other codes are ok for me :)

R?mi

>
>
> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>
>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>> Hello all;
>>>
>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>
>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>
>>> Mike
>> Hi Mike,
>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>
>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>> and does the modCount check for each element because a call to the consumer can change the underlying map
>> so you can not do a modCount check only at the end.
>>
>> R?mi
>>
>> Here is the diff.
>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>> @@ -28,6 +28,7 @@
>> import java.io.*;
>> import java.lang.reflect.ParameterizedType;
>> import java.lang.reflect.Type;
>> +import java.util.function.BiConsumer;
>> import java.util.function.Consumer;
>> import java.util.function.BiFunction;
>> import java.util.function.Function;
>> @@ -2615,6 +2616,54 @@
>>      int   capacity()     { return table.length; }
>>      float loadFactor()   { return loadFactor;   }
>>
>> +
>> +    @Override
>> +    public void forEach(BiConsumer action) {
>> +        Objects.requireNonNull(action);
>> +        final int expectedModCount = modCount;
>> +        if (nullKeyEntry != null) {
>> +            forEachNullKey(expectedModCount, action);
>> +        }
>> +        Object[] table = this.table;
>> +        for(int index = 0; index < table.length; index++) {
>> +            Object item = table[index];
>> +            if (item == null) {
>> +                continue;
>> +            }
>> +            if (item instanceof HashMap.TreeBin) {
>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>> +                continue;
>> +            }
>> +            @SuppressWarnings("unchecked")
>> +            Entry entry = (Entry)item;
>> +            for (;entry != null; entry = (Entry)entry.next) {
>> +                if (expectedModCount != modCount) {
>> +                    throw new ConcurrentModificationException();
>> +                }
>> +                action.accept(entry.key, entry.value);
>> +            }
>> +        }
>> +    }
>> +
>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>> +        while (node != null) {
>> +            if (expectedModCount != modCount) {
>> +                throw new ConcurrentModificationException();
>> +            }
>> +            @SuppressWarnings("unchecked")
>> +            Entry entry = (Entry)node.entry;
>> +            action.accept(entry.key, entry.value);
>> +            node = (TreeNode)entry.next;
>> +        }
>> +    }
>> +
>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>> +        if (expectedModCount != modCount) {
>> +            throw new ConcurrentModificationException();
>> +        }
>> +        action.accept(null, nullKeyEntry.value);
>> +    }
>> +
>>      /**
>>       * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>       */
>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>> @@ -24,7 +24,8 @@
>>   */
>>
>> package java.util;
>> -import java.io.*;
>> +
>> +import java.util.function.BiConsumer;
>>
>> /**
>>   * 
    Hash table and linked list implementation of the Map interface,
>> @@ -470,4 +471,16 @@
>>      protected boolean removeEldestEntry(Map.Entry eldest) {
>>          return false;
>>      }
>> +
>> +    @Override
>> +    public void forEach(BiConsumer action) {
>> +        Objects.requireNonNull(action);
>> +        int expectedModCount = modCount;
>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>> +            if (expectedModCount != modCount) {
>> +                throw new ConcurrentModificationException();
>> +            }
>> +            action.accept(entry.key, entry.value);
>> +        }
>> +    }
>> }
>>
>>



From daniel.fuchs at oracle.com  Thu Jun 13 13:47:05 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 13 Jun 2013 15:47:05 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
Message-ID: <51B9CD59.5030409@oracle.com>

Hi,

Please find below an attempt at fixing
test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java

This is an intermittent failure which I haven't managed to reproduce,
so I am reduced to figure out what could have gone wrong by analyzing
the code.

AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
returns null - which I believe can only happen
when LogManager.getLogger() returns null.

I see that LogManager uses weak references to hold loggers - so my
suspicion is that one of the logger whose name had been returned by
getLoggerNames() has been gc'ed in between the two calls.

I have modified the code to accept this possibility - excluding the
two loggers for which the test itself holds a strong reference, as
these should not have been gc'ed.

I can't guarantee that it will fix the issue, but if it does not,
we will at least be able to disregard this possibility :-)



-- daniel


From forax at univ-mlv.fr  Thu Jun 13 14:06:21 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 16:06:21 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
Message-ID: <51B9D1DD.60703@univ-mlv.fr>

On 06/13/2013 10:44 AM, Paul Sandoz wrote:
> On Jun 13, 2013, at 10:15 AM, Remi Forax  wrote:
>> On 06/13/2013 09:51 AM, Paul Sandoz wrote:
>>> On Jun 13, 2013, at 7:28 AM, Mike Duigou  wrote:
>>>
>>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>>>
>>>> Revised webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>>>
>>> The approach we have taken for bulk traversal of fail-fast spliterators and ArrayList/Vector is to check the mod count at the end of the loop. I think we should be consistent with those.
>>>
>>> Paul.
>> Hi Paul,
>> ArrayList.forEach() does the modCount check at each step.
> Doh, yes, i mis read the logic in the for statement in ArrayList/Vector.
>
>
>> There is a difference between an Iterator/forEach and a spliterator/stream,
>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>
> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>
>    ArrayList l = ...
>    l.stream().filter(...).forEach(e -> l.add(e));
>    l.spliterator().forEachRemaining(e -> l.add(e));
>
> and:
>
>    ArrayList l = ...
>    l.forEach(e -> l.add(e));
>    l.iterator().forEachRemaining(e -> l.add(e));
>
> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.

Isn't it because if you remove an element from an ArrayList while 
iterating you can see a stale value ?
While with a HashMap, if you have only one thread, you can not see a 
stale entry ?
So a spliterator on HashMap can only check the modCount at the end 
unlike the one on ArrayList that need to check at each step.

>
> So we are still inconsistent between Spliterator.forEachRemaining and Iterator.forEachReamining/Collection.forEach.
>
> Paul.

R?mi



From aleksej.efimov at oracle.com  Thu Jun 13 14:10:01 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 13 Jun 2013 18:10:01 +0400
Subject: RFR 8015978: Incorrect transformation of XPath expression
	"string(-0)"
In-Reply-To: <51B5FF13.9000802@oracle.com>
References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com>
	
	<51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com>
	<51B4C6F0.509@oracle.com> <51B4C82A.7070807@oracle.com>
	<51B5EA87.6090705@oracle.com> <51B5FF13.9000802@oracle.com>
Message-ID: <51B9D2B9.1080201@oracle.com>

Joe,
I have added the call to '!Double.isFinite(d)', the '-0.0' to '+0.0' 
conversion still there.
new webrev: http://cr.openjdk.java.net/~coffeys/webrev.8015978.v3/ 


Regards,
Aleksej

On 06/10/2013 08:30 PM, Joe Darcy wrote:
> Hi Aleksej,
>
> On 6/10/2013 8:02 AM, Aleksej Efimov wrote:
>> Hi Joe,
>> We can replace the "Double.isNaN(d) || Double.isInfinite(d)" with 
>> "!Double.isFinite(d)" - I agree that this one check looks better, but 
>> we still need to do the -0.0 -> 0.0 conversion to solve the reported 
>> problem. And as I understand (might be wrong) modification of this 
>> check won't help us to achieve this goal, we still need to do the 
>> conversion:
>> +            //Convert -0.0 to +0.0 other values remains the same
>> +            d = d + 0.0;
>> +
>
> Right; changing the set of Double.isFoo methods called earlier doesn't 
> change the need for the (d + 0.0) expression. I just noticed the 
> double isFoo calls when looking at the code and saw an opportunity to 
> use the new method.
>
> Cheers,
>
> -Joe
>
>
>> Regards,
>> -Aleksej
>>
>> On 06/09/2013 10:23 PM, Joe Darcy wrote:
>>> Hello Aleksej,
>>>
>>> Looking at the code, I have another suggestion. If this code can run 
>>> exclusively on JDK 8 or later, replace
>>>
>>>  955             if (Double.isNaN(d) || Double.isInfinite(d))
>>>  956                 return(Double.toString(d));
>>>
>>> with
>>>
>>>  955             if (!Double.isFinite(d))
>>>  956                 return(Double.toString(d));
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> On 6/9/2013 11:18 AM, Aleksej Efimov wrote:
>>>> Joe,
>>>>
>>>> I definitely like it:
>>>> 1. Its a one-line change - perfect size.
>>>> 2. Its fastest one from discussed previously.
>>>> 3. -0.0 -> 0.0 has tests.
>>>> 4. And it solves our problem.
>>>>
>>>> As a result of all props the next version of webrev: 
>>>> http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ 
>>>> 
>>>>
>>>> Thanks
>>>> -Aleksej
>>>>
>>>> On 06/07/2013 11:11 PM, huizhe wang wrote:
>>>>> Nice. One-line change, I guess Aleksej would love it :-)
>>>>>
>>>>> On 6/7/2013 10:19 AM, Joe Darcy wrote:
>>>>>> I'll do you one better; you can turn a negative zero into a 
>>>>>> positive zero leaving other values unchanged like this:
>>>>>>
>>>>>>     d = d + 0.0;
>>>>>>
>>>>>> In IEEE 754 under the round-to-nearest-even rounding mode 
>>>>>> required by Java
>>>>>>     -0.0 + 0.0 => (+)0.0
>>>>>>
>>>>>> This trick is used in various places in Java's numerical 
>>>>>> libraries, is required behavior by our specifications, and even 
>>>>>> has some tests for it :-)
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> On 6/7/2013 8:43 AM, David Chase wrote:
>>>>>>> Wouldn't be more efficient to do the following, assuming that 
>>>>>>> the full Java compilation chain respects the trickiness of 0 vs -0:
>>>>>>>
>>>>>>>     if (d == 0.0) {
>>>>>>>          d=0.0 // Jam -0 == +0 to +0, per 
>>>>>>> http://www.w3.org/TR/xpath/#function-string
>>>>>>>
>>>>>>>     }
>>>>>>>
>>>>>>> Division's plenty more expensive than assigning a constant, 
>>>>>>> especially on platforms that lack hardware FP division.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 2013-06-07, at 2:03 AM, huizhe wang  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Aleksej,
>>>>>>>>
>>>>>>>> According to XPath spec, both positive and negative zero are 
>>>>>>>> converted to the string 0, so it seems doesn't matter. But if 
>>>>>>>> you want to detect the negative zero, you may do the following:
>>>>>>>>     if (d == 0.0 && 1/d < 0.0) {
>>>>>>>>          d=0.0
>>>>>>>>     }
>>>>>>>>
>>>>>>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity).
>>>>>>>>
>>>>>>>> -Joe
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From paul.sandoz at oracle.com  Thu Jun 13 14:24:03 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 16:24:03 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B9C76D.2040905@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	<51B9C76D.2040905@univ-mlv.fr>
Message-ID: <6D07CCBC-EC1E-436E-94CD-207D35D44128@oracle.com>


On Jun 13, 2013, at 3:21 PM, Remi Forax  wrote:

> On 06/13/2013 07:28 AM, Mike Duigou wrote:
>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>> 
>> Revised webrev:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>> 
>> Mike
> 
> Hi Mike,
> 
> in TreeMap.forEach (and replaceAll), the check for co-modification should be done *before* action.accept(...)
> and not after because the semantics of the Iterator allows users to modify the map (hashmap or treemap)
> if it's the last element (so we should not check modCount after the last element).

That creates conditions that may or may not fail with a CME depending on the map implementation (e.g. if state is hoisted or referenced) and the state of the map instance e.g. if the size of the map is 1 or > 1 and the BiConsumer instance add a new value to the map. 

Interference caused by function values passed to collection/map bulk operations should always result in an CME regardless of the state of the collection/map instance.

Paul.



From paul.sandoz at oracle.com  Thu Jun 13 14:47:00 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 16:47:00 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B9D1DD.60703@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
Message-ID: <74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>

On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>> 
>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>> 
>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>> 
>>   ArrayList l = ...
>>   l.stream().filter(...).forEach(e -> l.add(e));
>>   l.spliterator().forEachRemaining(e -> l.add(e));
>> 
>> and:
>> 
>>   ArrayList l = ...
>>   l.forEach(e -> l.add(e));
>>   l.iterator().forEachRemaining(e -> l.add(e));
>> 
>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
> 
> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
> While with a HashMap, if you have only one thread, you can not see a stale entry ?

Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?


> So a spliterator on HashMap can only check the modCount at the end unlike the one on ArrayList that need to check at each step.
> 

The ArrayList.spliterator.forEachRemaining implementation also checks at the end.

Paul.

From mike.duigou at oracle.com  Thu Jun 13 15:42:49 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 13 Jun 2013 08:42:49 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <99ED5C0E-BDFF-4518-A54A-EB602D3EF0BD@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
	<51B969E3.6040109@gmail.com>
	<99ED5C0E-BDFF-4518-A54A-EB602D3EF0BD@oracle.com>
Message-ID: <8F3276B2-8FBD-4454-A5FF-46C8619B6839@oracle.com>


On Jun 13 2013, at 00:56 , Paul Sandoz wrote:

> 
> On Jun 13, 2013, at 8:42 AM, Peter Levart  wrote:
> 
>> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>> 
>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>> Hello all;
>>>>> 
>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>> 
>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>> 
>>>>> Mike
>>>> Hi Mike,
>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>> 
>> The javadoc for Map.forEach says differently:
>> 
>> default void forEach(BiConsumer  ,? superV  > action)
>> 
>> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)

Would anyone object to removing the ", in the order entries are returned by an entry set iterator (which may be unspecified)" clause? It seems like unnecessary over-specification.

Mike


> Right, LinkedHashMap should preserve the encounter order on traversal, bulk or otherwise.
> 
> Note that there is a bug logged against LinkedHashMap.spliterator. It should but currently does not report ORDERED for key/value/entry Spliterators.
> 
> Paul.



From paul.sandoz at oracle.com  Thu Jun 13 16:00:47 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Jun 2013 18:00:47 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <8F3276B2-8FBD-4454-A5FF-46C8619B6839@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
	<51B969E3.6040109@gmail.com>
	<99ED5C0E-BDFF-4518-A54A-EB602D3EF0BD@oracle.com>
	<8F3276B2-8FBD-4454-A5FF-46C8619B6839@oracle.com>
Message-ID: <17B129FF-3E0C-4113-B2FE-83FE2CBA89AE@oracle.com>


On Jun 13, 2013, at 5:42 PM, Mike Duigou  wrote:

> 
> On Jun 13 2013, at 00:56 , Paul Sandoz wrote:
> 
>> 
>> On Jun 13, 2013, at 8:42 AM, Peter Levart  wrote:
>> 
>>> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>> 
>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>> 
>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>> 
>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>> 
>>>>>> Mike
>>>>> Hi Mike,
>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>>> 
>>> The javadoc for Map.forEach says differently:
>>> 
>>> default void forEach(BiConsumer  ,? superV  > action)
>>> 
>>> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)
> 
> Would anyone object to removing the ", in the order entries are returned by an entry set iterator (which may be unspecified)" clause? It seems like unnecessary over-specification.
> 

Perhaps we can state something like:

"Unless otherwise documented by overriding implementations the order in which of entries are encountered is undefined".

Paul.

From chris.hegarty at oracle.com  Thu Jun 13 17:35:15 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 13 Jun 2013 17:35:15 +0000
Subject: hg: jdk8/tl/jdk: 7181748: java/lang/ThreadGroup/Suspend.java test
	fails intermittently
Message-ID: <20130613173549.E09D6481D3@hg.openjdk.java.net>

Changeset: f3609297a868
Author:    igerasim
Date:      2013-06-13 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3609297a868

7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently
Reviewed-by: chegar, dholmes

! test/java/lang/ThreadGroup/Suspend.java



From christian.thalinger at oracle.com  Thu Jun 13 17:51:40 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 13 Jun 2013 10:51:40 -0700
Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes
	scalability
In-Reply-To: 
References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr>
	<51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com>
	<88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com>
	<51B6E40A.9050904@oracle.com>
	<30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com>
	<51B74A36.8010802@oracle.com>
	<53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com>
	<51B74B7B.7010104@oracle.com>
	<3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com>
	<51B794E9.2040405@oracle.com>
	
Message-ID: 


On Jun 11, 2013, at 7:16 PM, Christian Thalinger  wrote:

> 
> On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev  wrote:
> 
>> On 06/11/2013 10:24 PM, Christian Thalinger wrote:
>>> 
>>> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev  wrote:
>>> 
>>>> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
>>>>> Anyway, let's push this.
>>>> 
>>>> Do you want me any other testing done? vm.mlvm.testlist is OK, but I
>>>> haven't done the full JPRT test cycle, only the build one.
>>> 
>>> You could do a full Nashorn 262 run.  That would shake out bugs.
>> 
>> Done. Linux x86_64/release passes test262parallel with either clean or
>> patched build.
> 
> Thanks for verifying.  I'll push your change tomorrow.

While preparing the push I noticed the new code gives a warning:

src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast
                T that = ((WeakEntry) obj).get();
                                         ^
  required: WeakEntry
  found:    Object
  where T is a type-variable:
    T extends Object declared in class WeakEntry
1 warning

Could you fix that, please?

-- Chris

> 
> -- Chris
> 
>> 
>> -Aleksey.
>> 
> 



From kurchi.subhra.hazra at oracle.com  Thu Jun 13 18:12:50 2013
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Thu, 13 Jun 2013 18:12:50 +0000
Subject: hg: jdk8/tl/jdk: 8015421: NegativeArraySizeException occurs in
	ChunkedOutputStream() with Integer.MAX_VALUE
Message-ID: <20130613181312.3B1E0481D4@hg.openjdk.java.net>

Changeset: ff83bd43e36a
Author:    khazra
Date:      2013-06-13 11:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff83bd43e36a

8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE
Summary: Ensure integer overflow does not occur
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/ChunkedOutputStream.java



From aleksey.shipilev at oracle.com  Thu Jun 13 19:09:28 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 13 Jun 2013 23:09:28 +0400
Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes
	scalability
In-Reply-To: 
References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr>
	<51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com>
	<88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com>
	<51B6E40A.9050904@oracle.com>
	<30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com>
	<51B74A36.8010802@oracle.com>
	<53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com>
	<51B74B7B.7010104@oracle.com>
	<3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com>
	<51B794E9.2040405@oracle.com>
	
	
Message-ID: <51BA18E8.50806@oracle.com>

On 06/13/2013 09:51 PM, Christian Thalinger wrote:
> While preparing the push I noticed the new code gives a warning:
> 
> src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast
>                 T that = ((WeakEntry) obj).get();
>                                          ^
>   required: WeakEntry
>   found:    Object
>   where T is a type-variable:
>     T extends Object declared in class WeakEntry
> 1 warning
> 
> Could you fix that, please?

Can't reproduce that warning in my builds (are you having
-Xlint:unchecked enabled in the new build system somehow?), but good
catch! There is the preceding instanceof check that ought to make this
cast safe now. Also we don't need to declare locals as T in equals().

Please try this:
   http://cr.openjdk.java.net/~shade/7177472/webrev.03/

This seems a trivial change, so I only tested java/lang/invoke
regression tests afterwards, those are OK.

-Aleksey.


From christian.thalinger at oracle.com  Thu Jun 13 19:30:19 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 13 Jun 2013 12:30:19 -0700
Subject: RFR (S) CR 7177472: JSR292: MethodType interning penalizes
	scalability
In-Reply-To: <51BA18E8.50806@oracle.com>
References: <51B1AF6C.5030708@oracle.com> <51B3059A.4030703@univ-mlv.fr>
	<51B39158.5000003@gmail.com> <51B5F519.6030307@oracle.com>
	<88A746DA-01FA-45D3-8774-1FEB5D37BACD@oracle.com>
	<51B6E40A.9050904@oracle.com>
	<30766CB2-AE19-40F4-A421-0A9F95354E77@oracle.com>
	<51B74A36.8010802@oracle.com>
	<53779644-0687-4BE9-BDF3-3AD2C2BC8F82@oracle.com>
	<51B74B7B.7010104@oracle.com>
	<3EE865B5-3E35-4D08-9888-21AEAD69B9E6@oracle.com>
	<51B794E9.2040405@oracle.com>
	
	
	<51BA18E8.50806@oracle.com>
Message-ID: <7F418E0A-03EF-49C8-A3C7-63331C0CDC1B@oracle.com>


On Jun 13, 2013, at 12:09 PM, Aleksey Shipilev  wrote:

> On 06/13/2013 09:51 PM, Christian Thalinger wrote:
>> While preparing the push I noticed the new code gives a warning:
>> 
>> src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked] unchecked cast
>>                T that = ((WeakEntry) obj).get();
>>                                         ^
>>  required: WeakEntry
>>  found:    Object
>>  where T is a type-variable:
>>    T extends Object declared in class WeakEntry
>> 1 warning
>> 
>> Could you fix that, please?
> 
> Can't reproduce that warning in my builds (are you having
> -Xlint:unchecked enabled in the new build system somehow?)

More or less.  I'm only building java/lang/invoke plus friends and use -Xlint:unchecked.

> , but good
> catch! There is the preceding instanceof check that ought to make this
> cast safe now. Also we don't need to declare locals as T in equals().
> 
> Please try this:
>   http://cr.openjdk.java.net/~shade/7177472/webrev.03/
> 
> This seems a trivial change, so I only tested java/lang/invoke
> regression tests afterwards, those are OK.

Looks good now.  Thanks for the quick turnaround.

-- Chris

> 
> -Aleksey.



From brent.christian at oracle.com  Thu Jun 13 19:46:56 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 13 Jun 2013 12:46:56 -0700
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: <51B934A9.8000103@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B934A9.8000103@oracle.com>
Message-ID: <51BA21B0.8030008@oracle.com>

On 6/12/13 7:55 PM, David Holmes wrote:
> Something of an aside but ...
>
> On 13/06/2013 3:45 AM, Martin Buchholz wrote:
>> Hi Brent,
>>
>> Thanks for doing this.
>>
>> Your webrev does not include mercurial changeset information, which I
>> think
>> is supported by recent webrevs.
>
> Given the changeset has to be created after the review is complete
> most/many people will not have a changeset prepared at review time.

That's it exactly.  If at all possible, I don't commit until the code 
has completed code review.  I tell webrev to do its thing based on 
modified files, rather than outgoing changesets.

-Brent


From mandy.chung at oracle.com  Thu Jun 13 20:05:21 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 13 Jun 2013 13:05:21 -0700
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51B9CD59.5030409@oracle.com>
References: <51B9CD59.5030409@oracle.com>
Message-ID: <51BA2601.3070609@oracle.com>

Daniel,

I wonder what the list of logger names (loggers1 and loggers2) returned 
by LoggingMXBean contains and that may include loggers in the running VM 
other than the ones created and kept a strong reference by the test.   
In other words,  would it be possible for the running VM that has 
loggers that are not created by the test and got GC'ed?

Mandy

On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below an attempt at fixing
> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
>
> This is an intermittent failure which I haven't managed to reproduce,
> so I am reduced to figure out what could have gone wrong by analyzing
> the code.
>
> AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
> returns null - which I believe can only happen
> when LogManager.getLogger() returns null.
>
> I see that LogManager uses weak references to hold loggers - so my
> suspicion is that one of the logger whose name had been returned by
> getLoggerNames() has been gc'ed in between the two calls.
>
> I have modified the code to accept this possibility - excluding the
> two loggers for which the test itself holds a strong reference, as
> these should not have been gc'ed.
>
> I can't guarantee that it will fix the issue, but if it does not,
> we will at least be able to disregard this possibility :-)
>
> 
>
> -- daniel



From forax at univ-mlv.fr  Thu Jun 13 21:48:40 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 23:48:40 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <8F3276B2-8FBD-4454-A5FF-46C8619B6839@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<6CA34B1A-2BDE-4F0B-85C8-A353EC5DFFF1@oracle.com>
	<51B969E3.6040109@gmail.com>
	<99ED5C0E-BDFF-4518-A54A-EB602D3EF0BD@oracle.com>
	<8F3276B2-8FBD-4454-A5FF-46C8619B6839@oracle.com>
Message-ID: <51BA3E38.6070307@univ-mlv.fr>

On 06/13/2013 05:42 PM, Mike Duigou wrote:
> On Jun 13 2013, at 00:56 , Paul Sandoz wrote:
>
>> On Jun 13, 2013, at 8:42 AM, Peter Levart  wrote:
>>
>>> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>
>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>>
>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>>
>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>>
>>>>>> Mike
>>>>> Hi Mike,
>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>>> The javadoc for Map.forEach says differently:
>>>
>>> default void forEach(BiConsumer  ,? superV  > action)
>>>
>>> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)
> Would anyone object to removing the ", in the order entries are returned by an entry set iterator (which may be unspecified)" clause? It seems like unnecessary over-specification.
>
> Mike

No :)
I think it's an important property because with that property people can 
refactor from a for(:map.entrySet()) to a map.forEach() and vice-versa.

R?mi

>
>
>> Right, LinkedHashMap should preserve the encounter order on traversal, bulk or otherwise.
>>
>> Note that there is a bug logged against LinkedHashMap.spliterator. It should but currently does not report ORDERED for key/value/entry Spliterators.
>>
>> Paul.



From forax at univ-mlv.fr  Thu Jun 13 21:56:08 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 13 Jun 2013 23:56:08 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
Message-ID: <51BA3FF8.7080006@univ-mlv.fr>

On 06/13/2013 04:47 PM, Paul Sandoz wrote:
> On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>
>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>
>>>    ArrayList l = ...
>>>    l.stream().filter(...).forEach(e -> l.add(e));
>>>    l.spliterator().forEachRemaining(e -> l.add(e));
>>>
>>> and:
>>>
>>>    ArrayList l = ...
>>>    l.forEach(e -> l.add(e));
>>>    l.iterator().forEachRemaining(e -> l.add(e));
>>>
>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?

yes, as I said to Mike, what is important IMO is that the semantics of 
forEach and the semantics of for(:) should be the same.

>
>
>> So a spliterator on HashMap can only check the modCount at the end unlike the one on ArrayList that need to check at each step.
>>
> The ArrayList.spliterator.forEachRemaining implementation also checks at the end.

Given that a spliterator is something new which is weaker than an 
iterator, the semantics can be relaxed.
For ArrayList, because you can see a stale entry if you mutate during a 
forEachRemaining,
you have no choice but checking at each step. And because the semantics 
is not tight to the iterator one,
I agree that you can also perform a check at the end.
For HashMap.spliterator.forEachRemaining,  because you can not see stale 
entry (without concurrency),
you can only perform a check at the end. It's IMO also a valid semantics.

>
> Paul.

R?mi



From daniel.fuchs at oracle.com  Thu Jun 13 22:17:14 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Jun 2013 00:17:14 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51BA2601.3070609@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
Message-ID: <51BA44EA.1020209@oracle.com>

On 6/13/13 10:05 PM, Mandy Chung wrote:
> Daniel,
>
> I wonder what the list of logger names (loggers1 and loggers2) 
> returned by LoggingMXBean contains and that may include loggers in the 
> running VM other than the ones created and kept a strong reference by 
> the test.   In other words,  would it be possible for the running VM 
> that has loggers that are not created by the test and got GC'ed?

That's exactly my suspicion. But since I haven't reproduced the issue 
it's impossible to say for sure.
I could try to print the list - maybe we would see if it already 
contains more than two loggers.

best regards,

-- daniel
>
> Mandy
>
> On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below an attempt at fixing
>> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
>>
>> This is an intermittent failure which I haven't managed to reproduce,
>> so I am reduced to figure out what could have gone wrong by analyzing
>> the code.
>>
>> AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
>> returns null - which I believe can only happen
>> when LogManager.getLogger() returns null.
>>
>> I see that LogManager uses weak references to hold loggers - so my
>> suspicion is that one of the logger whose name had been returned by
>> getLoggerNames() has been gc'ed in between the two calls.
>>
>> I have modified the code to accept this possibility - excluding the
>> two loggers for which the test itself holds a strong reference, as
>> these should not have been gc'ed.
>>
>> I can't guarantee that it will fix the issue, but if it does not,
>> we will at least be able to disregard this possibility :-)
>>
>> 
>>
>> -- daniel
>



From mike.duigou at oracle.com  Thu Jun 13 23:27:24 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 13 Jun 2013 16:27:24 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BA3FF8.7080006@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
Message-ID: 


On Jun 13 2013, at 14:56 , Remi Forax wrote:

> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>> On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>> 
>>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>> 
>>>>   ArrayList l = ...
>>>>   l.stream().filter(...).forEach(e -> l.add(e));
>>>>   l.spliterator().forEachRemaining(e -> l.add(e));
>>>> 
>>>> and:
>>>> 
>>>>   ArrayList l = ...
>>>>   l.forEach(e -> l.add(e));
>>>>   l.iterator().forEachRemaining(e -> l.add(e));
>>>> 
>>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
>> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?
> 
> yes, as I said to Mike, what is important IMO is that the semantics of forEach and the semantics of for(:) should be the same.

This seems like an undue restriction unless the order of elements in the entry set is specified. Otherwise it implies a dependence upon an unspecified order. To guarantee that forEach and for(:entrySet) will use the same unspecified order seems an inappropriate. Would you tolerate:

     * Performs the given action on each entry in this map until all entries 
     * have been processed or the action throws an {@code Exception}.
     * Exceptions thrown by the action are relayed to the caller. The entries
     * will be processed in entry set iterator order unless that order is
     * unspecified in which case implementations may use an order which differs
     * from the entry set iterator.

I really want to avoid tying the hands of future implementators. The most frustrating specifications to conform to are those which were unnecessary or poor judgement.

Mike



From kurchi.subhra.hazra at oracle.com  Fri Jun 14 00:37:49 2013
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Fri, 14 Jun 2013 00:37:49 +0000
Subject: hg: jdk8/tl/jdk: 7169142: CookieHandler does not work with localhost
Message-ID: <20130614003806.A6F86481E9@hg.openjdk.java.net>

Changeset: 42f9ad39bf42
Author:    khazra
Date:      2013-06-13 17:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42f9ad39bf42

7169142: CookieHandler does not work with localhost
Summary: Add .local to derived effective hostnames without dot
Reviewed-by: chegar

! src/share/classes/java/net/CookieManager.java
+ test/java/net/CookieHandler/LocalHostCookie.java



From joe.darcy at oracle.com  Fri Jun 14 04:54:00 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 13 Jun 2013 21:54:00 -0700
Subject: RFR 8015978: Incorrect transformation of XPath expression
	"string(-0)"
In-Reply-To: <51B9D2B9.1080201@oracle.com>
References: <51B0C28D.7080100@oracle.com> <51B177BD.1000905@oracle.com>
	
	<51B21632.2020309@oracle.com> <51B23070.6020006@oracle.com>
	<51B4C6F0.509@oracle.com> <51B4C82A.7070807@oracle.com>
	<51B5EA87.6090705@oracle.com> <51B5FF13.9000802@oracle.com>
	<51B9D2B9.1080201@oracle.com>
Message-ID: <51BAA1E8.4060400@oracle.com>

Hi Aleksej,

Source changes look fine; thanks,

-Joe

On 6/13/2013 7:10 AM, Aleksej Efimov wrote:
> Joe,
> I have added the call to '!Double.isFinite(d)', the '-0.0' to '+0.0' 
> conversion still there.
> new webrev: http://cr.openjdk.java.net/~coffeys/webrev.8015978.v3/ 
> 
>
> Regards,
> Aleksej
>
> On 06/10/2013 08:30 PM, Joe Darcy wrote:
>> Hi Aleksej,
>>
>> On 6/10/2013 8:02 AM, Aleksej Efimov wrote:
>>> Hi Joe,
>>> We can replace the "Double.isNaN(d) || Double.isInfinite(d)" with 
>>> "!Double.isFinite(d)" - I agree that this one check looks better, 
>>> but we still need to do the -0.0 -> 0.0 conversion to solve the 
>>> reported problem. And as I understand (might be wrong) modification 
>>> of this check won't help us to achieve this goal, we still need to 
>>> do the conversion:
>>> +            //Convert -0.0 to +0.0 other values remains the same
>>> +            d = d + 0.0;
>>> +
>>
>> Right; changing the set of Double.isFoo methods called earlier 
>> doesn't change the need for the (d + 0.0) expression. I just noticed 
>> the double isFoo calls when looking at the code and saw an 
>> opportunity to use the new method.
>>
>> Cheers,
>>
>> -Joe
>>
>>
>>> Regards,
>>> -Aleksej
>>>
>>> On 06/09/2013 10:23 PM, Joe Darcy wrote:
>>>> Hello Aleksej,
>>>>
>>>> Looking at the code, I have another suggestion. If this code can 
>>>> run exclusively on JDK 8 or later, replace
>>>>
>>>>  955             if (Double.isNaN(d) || Double.isInfinite(d))
>>>>  956                 return(Double.toString(d));
>>>>
>>>> with
>>>>
>>>>  955             if (!Double.isFinite(d))
>>>>  956                 return(Double.toString(d));
>>>>
>>>> Cheers,
>>>>
>>>> -Joe
>>>>
>>>> On 6/9/2013 11:18 AM, Aleksej Efimov wrote:
>>>>> Joe,
>>>>>
>>>>> I definitely like it:
>>>>> 1. Its a one-line change - perfect size.
>>>>> 2. Its fastest one from discussed previously.
>>>>> 3. -0.0 -> 0.0 has tests.
>>>>> 4. And it solves our problem.
>>>>>
>>>>> As a result of all props the next version of webrev: 
>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8015978.v2/ 
>>>>> 
>>>>>
>>>>> Thanks
>>>>> -Aleksej
>>>>>
>>>>> On 06/07/2013 11:11 PM, huizhe wang wrote:
>>>>>> Nice. One-line change, I guess Aleksej would love it :-)
>>>>>>
>>>>>> On 6/7/2013 10:19 AM, Joe Darcy wrote:
>>>>>>> I'll do you one better; you can turn a negative zero into a 
>>>>>>> positive zero leaving other values unchanged like this:
>>>>>>>
>>>>>>>     d = d + 0.0;
>>>>>>>
>>>>>>> In IEEE 754 under the round-to-nearest-even rounding mode 
>>>>>>> required by Java
>>>>>>>     -0.0 + 0.0 => (+)0.0
>>>>>>>
>>>>>>> This trick is used in various places in Java's numerical 
>>>>>>> libraries, is required behavior by our specifications, and even 
>>>>>>> has some tests for it :-)
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>> On 6/7/2013 8:43 AM, David Chase wrote:
>>>>>>>> Wouldn't be more efficient to do the following, assuming that 
>>>>>>>> the full Java compilation chain respects the trickiness of 0 vs 
>>>>>>>> -0:
>>>>>>>>
>>>>>>>>     if (d == 0.0) {
>>>>>>>>          d=0.0 // Jam -0 == +0 to +0, per 
>>>>>>>> http://www.w3.org/TR/xpath/#function-string
>>>>>>>>
>>>>>>>>     }
>>>>>>>>
>>>>>>>> Division's plenty more expensive than assigning a constant, 
>>>>>>>> especially on platforms that lack hardware FP division.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 2013-06-07, at 2:03 AM, huizhe wang  
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Aleksej,
>>>>>>>>>
>>>>>>>>> According to XPath spec, both positive and negative zero are 
>>>>>>>>> converted to the string 0, so it seems doesn't matter. But if 
>>>>>>>>> you want to detect the negative zero, you may do the following:
>>>>>>>>>     if (d == 0.0 && 1/d < 0.0) {
>>>>>>>>>          d=0.0
>>>>>>>>>     }
>>>>>>>>>
>>>>>>>>> Recognizing that (-0.0 == 0.0), and (1/(-0.0) == -Infinity).
>>>>>>>>>
>>>>>>>>> -Joe
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From forax at univ-mlv.fr  Fri Jun 14 07:16:45 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Jun 2013 09:16:45 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	
Message-ID: <51BAC35D.7010700@univ-mlv.fr>

On 06/14/2013 01:27 AM, Mike Duigou wrote:
> On Jun 13 2013, at 14:56 , Remi Forax wrote:
>
>> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>>> On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>>>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>>>
>>>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.stream().filter(...).forEach(e -> l.add(e));
>>>>>    l.spliterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> and:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.forEach(e -> l.add(e));
>>>>>    l.iterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>>>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>>>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
>>> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?
>> yes, as I said to Mike, what is important IMO is that the semantics of forEach and the semantics of for(:) should be the same.
> This seems like an undue restriction unless the order of elements in the entry set is specified. Otherwise it implies a dependence upon an unspecified order. To guarantee that forEach and for(:entrySet) will use the same unspecified order seems an inappropriate. Would you tolerate:
>
>       * Performs the given action on each entry in this map until all entries
>       * have been processed or the action throws an {@code Exception}.
>       * Exceptions thrown by the action are relayed to the caller. The entries
>       * will be processed in entry set iterator order unless that order is
>       * unspecified in which case implementations may use an order which differs
>       * from the entry set iterator.
>
> I really want to avoid tying the hands of future implementators.

Noble goal :)
Exceptions can be only unchecked exceptions (Error or RuntimeException).
Otherwise the wording are Ok for me.

> The most frustrating specifications to conform to are those which were unnecessary or poor judgement.

BTW, I've a following patch for HashMap only that clean the dirt;
remove all warnings, remove all unused variables, unnecessary cast, 
unecessary generated constructors, etc.
Could you create a bug for that ?

>
> Mike
>

R?mi



From paul.sandoz at oracle.com  Fri Jun 14 09:20:14 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 14 Jun 2013 11:20:14 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BA3FF8.7080006@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
Message-ID: <5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>


On Jun 13, 2013, at 11:56 PM, Remi Forax  wrote:

> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>> On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>> 
>>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>> 
>>>>   ArrayList l = ...
>>>>   l.stream().filter(...).forEach(e -> l.add(e));
>>>>   l.spliterator().forEachRemaining(e -> l.add(e));
>>>> 
>>>> and:
>>>> 
>>>>   ArrayList l = ...
>>>>   l.forEach(e -> l.add(e));
>>>>   l.iterator().forEachRemaining(e -> l.add(e));
>>>> 
>>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
>> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?
> 
> yes, as I said to Mike, what is important IMO is that the semantics of forEach and the semantics of for(:) should be the same.
> 
>> 
>> 
>>> So a spliterator on HashMap can only check the modCount at the end unlike the one on ArrayList that need to check at each step.
>>> 
>> The ArrayList.spliterator.forEachRemaining implementation also checks at the end.
> 
> Given that a spliterator is something new which is weaker than an iterator, the semantics can be relaxed.

In terms of traversal I don't see a spliterator from an ArrayList being weaker than an iterator from an ArrayList. I would argue Iterator has a weaker model of traversal.

The following does not throw CME:

            List l = new ArrayList<>(Arrays.asList(1, 2));
            for (Integer i : l) {
                l.remove(1);  // 2 is never encountered
            }

Where as the following does:

            List l = new ArrayList<>(Arrays.asList(1, 2, 3));
            for (Integer i : l) {
                l.remove(1);
            }

Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(

This behaviour sucks. It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.


> For ArrayList, because you can see a stale entry if you mutate during a forEachRemaining,
> you have no choice but checking at each step.

A CME does not make any hard guarantees, thus cannot be used for correctness. I think this comes down to a balance of performance and how fast the fail-fast should be. I can definitely see an argument for failing ASAP so as not to report dodgy data.

Paul.

> And because the semantics is not tight to the iterator one,
> I agree that you can also perform a check at the end.
> For HashMap.spliterator.forEachRemaining,  because you can not see stale entry (without concurrency),
> you can only perform a check at the end. It's IMO also a valid semantics.
> 
>> 
>> Paul.
> 
> R?mi
> 



From forax at univ-mlv.fr  Fri Jun 14 10:12:27 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Jun 2013 12:12:27 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
Message-ID: <51BAEC8B.6010200@univ-mlv.fr>

On 06/14/2013 11:20 AM, Paul Sandoz wrote:
> On Jun 13, 2013, at 11:56 PM, Remi Forax  wrote:
>
>> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>>> On Jun 13, 2013, at 4:06 PM, Remi Forax  wrote:
>>>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>>>
>>>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.stream().filter(...).forEach(e -> l.add(e));
>>>>>    l.spliterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> and:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.forEach(e -> l.add(e));
>>>>>    l.iterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>>>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>>>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
>>> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?
>> yes, as I said to Mike, what is important IMO is that the semantics of forEach and the semantics of for(:) should be the same.
>>
>>>
>>>> So a spliterator on HashMap can only check the modCount at the end unlike the one on ArrayList that need to check at each step.
>>>>
>>> The ArrayList.spliterator.forEachRemaining implementation also checks at the end.
>> Given that a spliterator is something new which is weaker than an iterator, the semantics can be relaxed.
> In terms of traversal I don't see a spliterator from an ArrayList being weaker than an iterator from an ArrayList. I would argue Iterator has a weaker model of traversal.

I was taking about spliterator in general, not the one of ArrayList 
which can not be weaker as I have explained below.

>
> The following does not throw CME:
>
>              List l = new ArrayList<>(Arrays.asList(1, 2));
>              for (Integer i : l) {
>                  l.remove(1);  // 2 is never encountered
>              }
>
> Where as the following does:
>
>              List l = new ArrayList<>(Arrays.asList(1, 2, 3));
>              for (Integer i : l) {
>                  l.remove(1);
>              }
>
> Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(
>
> This behaviour sucks.

devil advocate: why exactly, the iteration is finished when you remove 
the element ?

> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.

While I could agree with you in theory, in practice I have seen several 
times codes that rely on this behaviour,
usually there is a bunch of method calls between the for loop and the 
list.remove() so this is not something that can be easily fixed.
And because I think it's more important that users should be able to use 
either for(:) or forEach without thinking too much,
because otherwise nodoby will "modernize" their code, we have no choice 
but stick to the iterator behaviour for forEach
i.e. no modCount check at the end.

>
>
>> For ArrayList, because you can see a stale entry if you mutate during a forEachRemaining,
>> you have no choice but checking at each step.
> A CME does not make any hard guarantees, thus cannot be used for correctness. I think this comes down to a balance of performance and how fast the fail-fast should be.

yes, declare modCount volatile and your performance vanish :(

>   I can definitely see an argument for failing ASAP so as not to report dodgy data.
>
> Paul.

cheers,
R?mi

>
>> And because the semantics is not tight to the iterator one,
>> I agree that you can also perform a check at the end.
>> For HashMap.spliterator.forEachRemaining,  because you can not see stale entry (without concurrency),
>> you can only perform a check at the end. It's IMO also a valid semantics.
>>
>>> Paul.
>> R?mi
>>



From paul.sandoz at oracle.com  Fri Jun 14 10:55:38 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 14 Jun 2013 12:55:38 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BAEC8B.6010200@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
Message-ID: <5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>

On Jun 14, 2013, at 12:12 PM, Remi Forax  wrote:
>> 
>> The following does not throw CME:
>> 
>>             List l = new ArrayList<>(Arrays.asList(1, 2));
>>             for (Integer i : l) {
>>                 l.remove(1);  // 2 is never encountered
>>             }
>> 
>> Where as the following does:
>> 
>>             List l = new ArrayList<>(Arrays.asList(1, 2, 3));
>>             for (Integer i : l) {
>>                 l.remove(1);
>>             }
>> 
>> Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(
>> 
>> This behaviour sucks.
> 
> devil advocate: why exactly, the iteration is finished when you remove the element ?

The latter because a CME is thrown; the former because hasNext returns false.

The above is an example of how a bug can be hidden depending on the state (# elements) of the collection.


> 
>> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.
> 
> While I could agree with you in theory, in practice I have seen several times codes that rely on this behaviour,
> usually there is a bunch of method calls between the for loop and the list.remove() so this is not something that can be easily fixed.

A bug none the less, yes?


> And because I think it's more important that users should be able to use either for(:) or forEach without thinking too much,
> because otherwise nodoby will "modernize" their code, we have no choice but stick to the iterator behaviour for forEach
> i.e. no modCount check at the end.
> 

So you argument is based on the the premise that existing buggy code should continue work?

Paul.

From paul.sandoz at oracle.com  Fri Jun 14 12:40:59 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 14 Jun 2013 14:40:59 +0200
Subject: RFR 8012987: Optimizations for Stream.limit/substream
Message-ID: <846D60F7-4D7D-48E2-9409-84DAB76F01AD@oracle.com>

Hi,

This patch implements optimizations for the limit/substream operations when input to those operations have certain properties (corresponding to known size or unordered) which helps to avoid out of memory issues (not all, we still have some more work to do).

The {Xxx}/Stream.generate methods have been modified to generate a known infinite stream of unordered elements. Previously an ordered known infinite stream of elements was generated, making it particularly prone to OOMEs. 

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8012987-slice/webrev/

-

This is based on the following in order, still requiring reviews (hint hint):

 http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/
 http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
 http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/

Plus:

 http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/  (Note this is not rebased in this version, but is in my patch queue)

Paul.



From forax at univ-mlv.fr  Fri Jun 14 12:41:15 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 14 Jun 2013 14:41:15 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
	<5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
Message-ID: <51BB0F6B.3080203@univ-mlv.fr>

On 06/14/2013 12:55 PM, Paul Sandoz wrote:
> On Jun 14, 2013, at 12:12 PM, Remi Forax  wrote:
>>> The following does not throw CME:
>>>
>>>              List l = new ArrayList<>(Arrays.asList(1, 2));
>>>              for (Integer i : l) {
>>>                  l.remove(1);  // 2 is never encountered
>>>              }
>>>
>>> Where as the following does:
>>>
>>>              List l = new ArrayList<>(Arrays.asList(1, 2, 3));
>>>              for (Integer i : l) {
>>>                  l.remove(1);
>>>              }
>>>
>>> Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(
>>>
>>> This behaviour sucks.
>> devil advocate: why exactly, the iteration is finished when you remove the element ?
> The latter because a CME is thrown; the former because hasNext returns false.
>
> The above is an example of how a bug can be hidden depending on the state (# elements) of the collection.
>
>
>>> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.
>> While I could agree with you in theory, in practice I have seen several times codes that rely on this behaviour,
>> usually there is a bunch of method calls between the for loop and the list.remove() so this is not something that can be easily fixed.
> A bug none the less, yes?

In the codes I was referring to, there was always a way to know that the 
remove was done at the end by example by knowing that the last element 
was a special sentinel or by using a counter.
So is the following program bugged ?

List l = new ArrayList<>(Arrays.asList(1, 2, null));
for (Integer i : l) {
   if (i == null) {
     l.set(l.size() - 1, 3);  // change the last value to 3
   }
}


>> And because I think it's more important that users should be able to use either for(:) or forEach without thinking too much,
>> because otherwise nodoby will "modernize" their code, we have no choice but stick to the iterator behaviour for forEach
>> i.e. no modCount check at the end.
>>
> So you argument is based on the the premise that existing buggy code should continue work?

buggy code or not buggy code, that is the question.

>
> Paul.

R?mi



From paul.sandoz at oracle.com  Fri Jun 14 13:19:55 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 14 Jun 2013 15:19:55 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BB0F6B.3080203@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
	<5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
	<51BB0F6B.3080203@univ-mlv.fr>
Message-ID: 

On Jun 14, 2013, at 2:41 PM, Remi Forax  wrote:
>> 
>>>> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.
>>> While I could agree with you in theory, in practice I have seen several times codes that rely on this behaviour,
>>> usually there is a bunch of method calls between the for loop and the list.remove() so this is not something that can be easily fixed.
>> A bug none the less, yes?
> 
> In the codes I was referring to, there was always a way to know that the remove was done at the end by example by knowing that the last element was a special sentinel or by using a counter.
> So is the following program bugged ?
> 

No, but gives off an unpleasant odour.


> List l = new ArrayList<>(Arrays.asList(1, 2, null));
> for (Integer i : l) {
>  if (i == null) {
>    l.set(l.size() - 1, 3);  // change the last value to 3
>  }
> }
> 

This works fine:

            List l = new ArrayList<>(Arrays.asList(1, 2, null));
            l.forEach(e -> {
                if (e == null) {
                    l.set(l.size() - 1, 3);  // change the last value to 3
                }
            });

The reason being is set() is not a structural modification. There is a grey area here to what constitutes a co-modification but usually the line is drawn at anything that structurally modifies the collection's data structure.

Paul.

From david.r.chase at oracle.com  Fri Jun 14 13:23:46 2013
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 14 Jun 2013 09:23:46 -0400
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BB0F6B.3080203@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
	<5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
	<51BB0F6B.3080203@univ-mlv.fr>
Message-ID: <7DE17ED2-8B7F-469F-ADC6-F186596EFA5F@oracle.com>


On 2013-06-14, at 8:41 AM, Remi Forax  wrote:
> In the codes I was referring to, there was always a way to know that the remove was done at the end by example by knowing that the last element was a special sentinel or by using a counter.
> So is the following program bugged ?
> 
> List l = new ArrayList<>(Arrays.asList(1, 2, null));
> for (Integer i : l) {
>  if (i == null) {
>    l.set(l.size() - 1, 3);  // change the last value to 3
>  }
> }

There will come a time when it should be considered buggy, yes.  Assume the future is parallel.  Java's intricately specified serial legacy may cause problems, and if it gets to the point that "every good programmer knows" that the rule is to sprinkle parallel-parallel-parallel-parallel throughout their code, they may eventually wander off to find another language.

David



From sean.coffey at oracle.com  Fri Jun 14 14:19:01 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Fri, 14 Jun 2013 14:19:01 +0000
Subject: hg: jdk8/tl/jdk: 8015978: Incorrect transformation of XPath
	expression "string(-0)"
Message-ID: <20130614141922.C91E148202@hg.openjdk.java.net>

Changeset: 45a3584bfacf
Author:    coffeys
Date:      2013-06-14 15:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45a3584bfacf

8015978: Incorrect transformation of XPath expression "string(-0)"
Reviewed-by: darcy, joehw
Contributed-by: aleksej.efimov at oracle.com

+ test/javax/xml/jaxp/XPath/8015978/XPathNegativeZero.java
+ test/javax/xml/jaxp/XPath/8015978/dummy.xml
+ test/javax/xml/jaxp/XPath/8015978/negativezero.xsl



From sean.coffey at oracle.com  Fri Jun 14 14:20:11 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Fri, 14 Jun 2013 14:20:11 +0000
Subject: hg: jdk8/tl/jaxp: 8015978: Incorrect transformation of XPath
	expression "string(-0)"
Message-ID: <20130614142015.3B72048203@hg.openjdk.java.net>

Changeset: 659828443145
Author:    coffeys
Date:      2013-06-14 15:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145

8015978: Incorrect transformation of XPath expression "string(-0)"
Reviewed-by: darcy, joehw
Contributed-by: aleksej.efimov at oracle.com

! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java



From chris.hegarty at oracle.com  Fri Jun 14 15:00:24 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 14 Jun 2013 16:00:24 +0100
Subject: RFR 623 build warnings [deprecation] isLoggable(int) in PlatformLogger
Message-ID: <51BB3008.8000306@oracle.com>

There are 623 occurrences, and hence 623 deprecated build warnings, of 
PlatformLogger.isLoggable(int) in the jdk source.

PlatformLogger is an internal API, and used in may places in the jdk. 
isLoggable(int) has been deprecated in favor of isLoggable(Level). 
isLoggable(Level) is slightly more efficient, as it avoids the mapping 
of int to Level.

The solution is to simply replace isLoggable(int) with 
isLoggable(Level), providing the appropriate Level. Example:

   -          if(logger.isLoggable(PlatformLogger.FINE)) {
   +          if(logger.isLoggable(PlatformLogger.Level.FINE)) {

http://cr.openjdk.java.net/~chegar/platLoggerWarn/webrev/

I haven't yet filed a bug for this, but I plan to push the changes 
through TL, rather than splitting the across multiple integration forests.

Sample warning output:

tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:416: 
warning: [deprecation] isLoggable(int) in PlatformLogger has been deprecated
tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:422: 
warning: [deprecation] isLoggable(int) in PlatformLogger has been deprecated
tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:635: 
warning: [deprecation] isLoggable(int) in PlatformLogger has been deprecated
....

-Chris.







From sean.mullan at oracle.com  Fri Jun 14 13:14:06 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Fri, 14 Jun 2013 13:14:06 +0000
Subject: hg: jdk8/tl/jdk: 8014307: Memory leak ...
	security/jgss/wrapper/GSSLibStub.c
Message-ID: <20130614131449.A9127481FD@hg.openjdk.java.net>

Changeset: f695f447f6b7
Author:    jzavgren
Date:      2013-06-14 09:13 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f695f447f6b7

8014307: Memory leak ... security/jgss/wrapper/GSSLibStub.c
Summary: I modified the native procedure: Java_sun_security_jgss_wrapper_GSSLibStub_initContext() so that allocated memory is freed when errors occur.
Reviewed-by: chegar, valeriep

! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c



From vicente.romero at oracle.com  Fri Jun 14 15:26:06 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 14 Jun 2013 15:26:06 +0000
Subject: hg: jdk8/tl/langtools: 8016569: javac,
	add new flag for polymorphic method signatures
Message-ID: <20130614152612.5822248206@hg.openjdk.java.net>

Changeset: 6b48ebae2569
Author:    vromero
Date:      2013-06-14 16:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b48ebae2569

8016569: javac, add new flag for polymorphic method signatures
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java



From joe.darcy at oracle.com  Fri Jun 14 16:25:51 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 14 Jun 2013 09:25:51 -0700
Subject: RFR 623 build warnings [deprecation] isLoggable(int) in
	PlatformLogger
In-Reply-To: <51BB3008.8000306@oracle.com>
References: <51BB3008.8000306@oracle.com>
Message-ID: <51BB440F.1040607@oracle.com>

Looks fine Chris; thanks,

-Joe

On 6/14/2013 8:00 AM, Chris Hegarty wrote:
> There are 623 occurrences, and hence 623 deprecated build warnings, of 
> PlatformLogger.isLoggable(int) in the jdk source.
>
> PlatformLogger is an internal API, and used in may places in the jdk. 
> isLoggable(int) has been deprecated in favor of isLoggable(Level). 
> isLoggable(Level) is slightly more efficient, as it avoids the mapping 
> of int to Level.
>
> The solution is to simply replace isLoggable(int) with 
> isLoggable(Level), providing the appropriate Level. Example:
>
>   -          if(logger.isLoggable(PlatformLogger.FINE)) {
>   +          if(logger.isLoggable(PlatformLogger.Level.FINE)) {
>
> http://cr.openjdk.java.net/~chegar/platLoggerWarn/webrev/
>
> I haven't yet filed a bug for this, but I plan to push the changes 
> through TL, rather than splitting the across multiple integration 
> forests.
>
> Sample warning output:
>
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:416: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:422: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:635: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> ....
>
> -Chris.
>
>
>
>
>



From vicente.romero at oracle.com  Fri Jun 14 17:02:19 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 14 Jun 2013 17:02:19 +0000
Subject: hg: jdk8/tl/langtools: 8008023: Get rid of utf8 chars in two tests
Message-ID: <20130614170225.739644820E@hg.openjdk.java.net>

Changeset: 1936a884b290
Author:    vromero
Date:      2013-06-14 18:01 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1936a884b290

8008023: Get rid of utf8 chars in two tests
Reviewed-by: jjg

! test/tools/javac/api/6437999/Utf8.java
! test/tools/javac/api/T6306137.java



From jason_mehrens at hotmail.com  Fri Jun 14 17:10:14 2013
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 14 Jun 2013 12:10:14 -0500
Subject: RFR 8009736: Comparator API cleanup
In-Reply-To: <51B790E6.6020209@oracle.com>
References: <51B790E6.6020209@oracle.com>
Message-ID: 

Any chance the static method Comparator.reverseOrder()  will be renamed to something like reversedNaturalOrder?  Now all of the calls to Comparator.reverseOrder() take on new meaning.
 
Jason
 
> Date: Tue, 11 Jun 2013 14:04:38 -0700
> From: henry.jen at oracle.com
> To: lambda-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: RFR 8009736: Comparator API cleanup
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
> 
> Highlight of changes,
> 
> - Comparators class is now only package-private implementations. The
> public static methods have been move to other arguably more appropriate
> places, mostly in Comparator.
> 
> - Comparator.reverseOrder() is renamed to Comparator.reversed()
> 
> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
> wrap up a comparator to be null-friendly.
> 
> To see the API changes, found the specdiff at
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
> 
> Cheers,
> Henry
 		 	   		  

From mike.duigou at oracle.com  Fri Jun 14 19:07:25 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 14 Jun 2013 12:07:25 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51B9C76D.2040905@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	<51B9C76D.2040905@univ-mlv.fr>
Message-ID: <886F7DCE-5280-4ECF-A2BB-F5B8B7A3F78B@oracle.com>


On Jun 13 2013, at 06:21 , Remi Forax wrote:

> On 06/13/2013 07:28 AM, Mike Duigou wrote:
>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>> 
>> Revised webrev:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>> 
>> Mike
> 
> Hi Mike,
> 
> in TreeMap.forEach (and replaceAll), the check for co-modification should be done *before* action.accept(...)
> and not after because the semantics of the Iterator allows users to modify the map (hashmap or treemap)
> if it's the last element (so we should not check modCount after the last element).

Not implementing the best "fast-fail" we can to emulate the weaker semantics of iterator seems like a disservice.

> Also the code of forEach inside the loop is basically a hand-inlined version of Treemap.successor(),

> I wonder if it's not better to use successor() here ?

A little microbenchmark indicates that successor() is not appreciably slower and a lot clearer.

> 
> 
> in Hashtable.replaceAll(), the cast to K and V in function.apply() is useless.

Fixed. I had moved the casts around and didn't notice that these ones were no longer needed.

> otherwise, all other codes are ok for me :)
> 
> R?mi
> 
>> 
>> 
>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>> 
>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>> Hello all;
>>>> 
>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>> 
>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>> 
>>>> Mike
>>> Hi Mike,
>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>> 
>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>> so you can not do a modCount check only at the end.
>>> 
>>> R?mi
>>> 
>>> Here is the diff.
>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -28,6 +28,7 @@
>>> import java.io.*;
>>> import java.lang.reflect.ParameterizedType;
>>> import java.lang.reflect.Type;
>>> +import java.util.function.BiConsumer;
>>> import java.util.function.Consumer;
>>> import java.util.function.BiFunction;
>>> import java.util.function.Function;
>>> @@ -2615,6 +2616,54 @@
>>>     int   capacity()     { return table.length; }
>>>     float loadFactor()   { return loadFactor;   }
>>> 
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        final int expectedModCount = modCount;
>>> +        if (nullKeyEntry != null) {
>>> +            forEachNullKey(expectedModCount, action);
>>> +        }
>>> +        Object[] table = this.table;
>>> +        for(int index = 0; index < table.length; index++) {
>>> +            Object item = table[index];
>>> +            if (item == null) {
>>> +                continue;
>>> +            }
>>> +            if (item instanceof HashMap.TreeBin) {
>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>> +                continue;
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)item;
>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>> +                if (expectedModCount != modCount) {
>>> +                    throw new ConcurrentModificationException();
>>> +                }
>>> +                action.accept(entry.key, entry.value);
>>> +            }
>>> +        }
>>> +    }
>>> +
>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>> +        while (node != null) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)node.entry;
>>> +            action.accept(entry.key, entry.value);
>>> +            node = (TreeNode)entry.next;
>>> +        }
>>> +    }
>>> +
>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>> +        if (expectedModCount != modCount) {
>>> +            throw new ConcurrentModificationException();
>>> +        }
>>> +        action.accept(null, nullKeyEntry.value);
>>> +    }
>>> +
>>>     /**
>>>      * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>      */
>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -24,7 +24,8 @@
>>>  */
>>> 
>>> package java.util;
>>> -import java.io.*;
>>> +
>>> +import java.util.function.BiConsumer;
>>> 
>>> /**
>>>  * 
    Hash table and linked list implementation of the Map interface,
>>> @@ -470,4 +471,16 @@
>>>     protected boolean removeEldestEntry(Map.Entry eldest) {
>>>         return false;
>>>     }
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        int expectedModCount = modCount;
>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            action.accept(entry.key, entry.value);
>>> +        }
>>> +    }
>>> }
>>> 
>>> 
> 



From mike.duigou at oracle.com  Fri Jun 14 19:45:31 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 14 Jun 2013 12:45:31 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51BB0F6B.3080203@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
	<5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
	<51BB0F6B.3080203@univ-mlv.fr>
Message-ID: 


On Jun 14 2013, at 05:41 , Remi Forax wrote:

> On 06/14/2013 12:55 PM, Paul Sandoz wrote:
>> On Jun 14, 2013, at 12:12 PM, Remi Forax  wrote:
>>>> The following does not throw CME:
>>>> 
>>>>             List l = new ArrayList<>(Arrays.asList(1, 2));
>>>>             for (Integer i : l) {
>>>>                 l.remove(1);  // 2 is never encountered
>>>>             }
>>>> 
>>>> Where as the following does:
>>>> 
>>>>             List l = new ArrayList<>(Arrays.asList(1, 2, 3));
>>>>             for (Integer i : l) {
>>>>                 l.remove(1);
>>>>             }
>>>> 
>>>> Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(
>>>> 
>>>> This behaviour sucks.
>>> devil advocate: why exactly, the iteration is finished when you remove the element ?
>> The latter because a CME is thrown; the former because hasNext returns false.
>> 
>> The above is an example of how a bug can be hidden depending on the state (# elements) of the collection.
>> 
>> 
>>>> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.
>>> While I could agree with you in theory, in practice I have seen several times codes that rely on this behaviour,
>>> usually there is a bunch of method calls between the for loop and the list.remove() so this is not something that can be easily fixed.
>> A bug none the less, yes?
> 
> In the codes I was referring to, there was always a way to know that the remove was done at the end by example by knowing that the last element was a special sentinel or by using a counter.
> So is the following program bugged ?
> 
> List l = new ArrayList<>(Arrays.asList(1, 2, null));
> for (Integer i : l) {
>  if (i == null) {
>    l.set(l.size() - 1, 3);  // change the last value to 3
>  }
> }

I would consider it bad form at minimum and probably buggy. Why insist on walking right next to the minefield? Sometimes minefields are poorly mapped (spec ambiguity), mines are misplaced (bugs) or you might stray (your bugs).

What is the objection to the much safer and general:

List l = new ArrayList<>(Arrays.asList(1, 2, null));
for(ListIterator each = l.listIterator(); each.hasNext();) {
  Integer i = each;
  if(i == null) {
     each.set(3);
  }
}

Just the lack of for(:) loop?

Mike

From martinrb at google.com  Fri Jun 14 20:36:53 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 14 Jun 2013 13:36:53 -0700
Subject: RFR 8010325 : Remove hash32() method and hash32 int field from
	java.lang.String
In-Reply-To: <51BA21B0.8030008@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B934A9.8000103@oracle.com> <51BA21B0.8030008@oracle.com>
Message-ID: 

On Thu, Jun 13, 2013 at 12:46 PM, Brent Christian <
brent.christian at oracle.com> wrote:

> On 6/12/13 7:55 PM, David Holmes wrote:
>
>> Something of an aside but ...
>>
>> On 13/06/2013 3:45 AM, Martin Buchholz wrote:
>>
>>> Hi Brent,
>>>
>>> Thanks for doing this.
>>>
>>> Your webrev does not include mercurial changeset information, which I
>>> think
>>> is supported by recent webrevs.
>>>
>>
>> Given the changeset has to be created after the review is complete
>> most/many people will not have a changeset prepared at review time.
>>
>
> That's it exactly.  If at all possible, I don't commit until the code has
> completed code review.  I tell webrev to do its thing based on modified
> files, rather than outgoing changesets.


Hmmm.... I've been using mq for so long it's hard for me to imagine working
without it.

It allows others to review the mercurial changeset metadata, which is also
the best summary to decide whether to review further.


From mike.duigou at oracle.com  Fri Jun 14 21:57:37 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 14 Jun 2013 14:57:37 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
Message-ID: 

I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.

http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/

For interference detection the strategy I am advocating is :

- serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.

- stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.

Mike

On Jun 12 2013, at 22:28 , Mike Duigou wrote:

> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
> 
> Revised webrev:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
> 
> Mike
> 
> 
> On Jun 12 2013, at 15:49 , Remi Forax wrote:
> 
>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>> Hello all;
>>> 
>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>> 
>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>> 
>>> Mike
>> 
>> Hi Mike,
>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>> 
>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>> and does the modCount check for each element because a call to the consumer can change the underlying map
>> so you can not do a modCount check only at the end.
>> 
>> R?mi
>> 
>> Here is the diff.
>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>> @@ -28,6 +28,7 @@
>> import java.io.*;
>> import java.lang.reflect.ParameterizedType;
>> import java.lang.reflect.Type;
>> +import java.util.function.BiConsumer;
>> import java.util.function.Consumer;
>> import java.util.function.BiFunction;
>> import java.util.function.Function;
>> @@ -2615,6 +2616,54 @@
>>    int   capacity()     { return table.length; }
>>    float loadFactor()   { return loadFactor;   }
>> 
>> +
>> +    @Override
>> +    public void forEach(BiConsumer action) {
>> +        Objects.requireNonNull(action);
>> +        final int expectedModCount = modCount;
>> +        if (nullKeyEntry != null) {
>> +            forEachNullKey(expectedModCount, action);
>> +        }
>> +        Object[] table = this.table;
>> +        for(int index = 0; index < table.length; index++) {
>> +            Object item = table[index];
>> +            if (item == null) {
>> +                continue;
>> +            }
>> +            if (item instanceof HashMap.TreeBin) {
>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>> +                continue;
>> +            }
>> +            @SuppressWarnings("unchecked")
>> +            Entry entry = (Entry)item;
>> +            for (;entry != null; entry = (Entry)entry.next) {
>> +                if (expectedModCount != modCount) {
>> +                    throw new ConcurrentModificationException();
>> +                }
>> +                action.accept(entry.key, entry.value);
>> +            }
>> +        }
>> +    }
>> +
>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>> +        while (node != null) {
>> +            if (expectedModCount != modCount) {
>> +                throw new ConcurrentModificationException();
>> +            }
>> +            @SuppressWarnings("unchecked")
>> +            Entry entry = (Entry)node.entry;
>> +            action.accept(entry.key, entry.value);
>> +            node = (TreeNode)entry.next;
>> +        }
>> +    }
>> +
>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>> +        if (expectedModCount != modCount) {
>> +            throw new ConcurrentModificationException();
>> +        }
>> +        action.accept(null, nullKeyEntry.value);
>> +    }
>> +
>>    /**
>>     * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>     */
>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>> @@ -24,7 +24,8 @@
>> */
>> 
>> package java.util;
>> -import java.io.*;
>> +
>> +import java.util.function.BiConsumer;
>> 
>> /**
>> * 
    Hash table and linked list implementation of the Map interface,
>> @@ -470,4 +471,16 @@
>>    protected boolean removeEldestEntry(Map.Entry eldest) {
>>        return false;
>>    }
>> +
>> +    @Override
>> +    public void forEach(BiConsumer action) {
>> +        Objects.requireNonNull(action);
>> +        int expectedModCount = modCount;
>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>> +            if (expectedModCount != modCount) {
>> +                throw new ConcurrentModificationException();
>> +            }
>> +            action.accept(entry.key, entry.value);
>> +        }
>> +    }
>> }
>> 
>> 
> 



From kurchi.subhra.hazra at oracle.com  Fri Jun 14 22:59:54 2013
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Fri, 14 Jun 2013 15:59:54 -0700
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51BB9065.4070704@oracle.com>
References: <51BB9065.4070704@oracle.com>
Message-ID: <51BBA06A.7060106@oracle.com>


Hi,
This is to elimnate the overrides warning from ClassDeclaration.java. 
This class is used by rmi, but sun/tools/java and
sun/tools/javac also heavily uses it, let me know if anyone else should 
also be reviewing it.

Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/

Thanks,
Kurchi



From forax at univ-mlv.fr  Fri Jun 14 23:29:36 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 15 Jun 2013 01:29:36 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	<51B97FBB.8020706@univ-mlv.fr>
	<3666C2B6-DB4C-425E-9269-8563C47D5672@oracle.com>
	<51B9D1DD.60703@univ-mlv.fr>
	<74A9F423-665D-4C48-8E79-7254C393562C@oracle.com>
	<51BA3FF8.7080006@univ-mlv.fr>
	<5196471D-EBB7-4153-ACD4-2D8CD0A94249@oracle.com>
	<51BAEC8B.6010200@univ-mlv.fr>
	<5C5AC4E3-D2F4-4B6E-933B-240923DFB51F@oracle.com>
	<51BB0F6B.3080203@univ-mlv.fr>
	
Message-ID: <51BBA760.9080509@univ-mlv.fr>

On 06/14/2013 09:45 PM, Mike Duigou wrote:
> On Jun 14 2013, at 05:41 , Remi Forax wrote:
>
>> On 06/14/2013 12:55 PM, Paul Sandoz wrote:
>>> On Jun 14, 2013, at 12:12 PM, Remi Forax  wrote:
>>>>> The following does not throw CME:
>>>>>
>>>>>              List l = new ArrayList<>(Arrays.asList(1, 2));
>>>>>              for (Integer i : l) {
>>>>>                  l.remove(1);  // 2 is never encountered
>>>>>              }
>>>>>
>>>>> Where as the following does:
>>>>>
>>>>>              List l = new ArrayList<>(Arrays.asList(1, 2, 3));
>>>>>              for (Integer i : l) {
>>>>>                  l.remove(1);
>>>>>              }
>>>>>
>>>>> Because the hasNext implementation does not check for modification. It's sad this also occurs for the default implementation of Iterable.forEach :-(
>>>>>
>>>>> This behaviour sucks.
>>>> devil advocate: why exactly, the iteration is finished when you remove the element ?
>>> The latter because a CME is thrown; the former because hasNext returns false.
>>>
>>> The above is an example of how a bug can be hidden depending on the state (# elements) of the collection.
>>>
>>>
>>>>> It would be a shame for overriding forEach/forEachRemaining implementations to conform to such behaviour when they can implement stronger/consistent failure guarantees.
>>>> While I could agree with you in theory, in practice I have seen several times codes that rely on this behaviour,
>>>> usually there is a bunch of method calls between the for loop and the list.remove() so this is not something that can be easily fixed.
>>> A bug none the less, yes?
>> In the codes I was referring to, there was always a way to know that the remove was done at the end by example by knowing that the last element was a special sentinel or by using a counter.
>> So is the following program bugged ?
>>
>> List l = new ArrayList<>(Arrays.asList(1, 2, null));
>> for (Integer i : l) {
>>   if (i == null) {
>>     l.set(l.size() - 1, 3);  // change the last value to 3
>>   }
>> }
> I would consider it bad form at minimum and probably buggy. Why insist on walking right next to the minefield? Sometimes minefields are poorly mapped (spec ambiguity), mines are misplaced (bugs) or you might stray (your bugs).
>
> What is the objection to the much safer and general:
>
> List l = new ArrayList<>(Arrays.asList(1, 2, null));
> for(ListIterator each = l.listIterator(); each.hasNext();) {
>    Integer i = each;
>    if(i == null) {
>       each.set(3);
>    }
> }
>
> Just the lack of for(:) loop?

I don't think so, I think the issue is usually because the real code is 
more something like:

List l = new ArrayList<>(Arrays.asList(1, 2, null));
for (Integer i : l) {
   blob.foo(l, i);
}

and in another module somewhere in the application

void bar(List l, Integer i) {
   if (i == null) {
    l.set(l.size() - 1, 3);  // change the last value to 3
  }

and it appear that sometimes blob.foo calls several layers of methods 
that end up to call bar.

So while obviously your code is how to fix the problem, usually people 
don't even notice the problem
because the code of the loop and the code that does the mutation are far 
away from each other.

>
> Mike

R?mi



From mike.duigou at oracle.com  Fri Jun 14 23:31:35 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 14 Jun 2013 16:31:35 -0700
Subject: RFR : 7129185 : (M) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
Message-ID: <0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>

Hi Martin;

Thanks, as always, for the feedback!

Louis Wasserman's question about existing methods delegating to newer methods and discussions regarding the serialization impacts with Stuart Marks lead me to reconsider the approach used in revision "3".

For revision "4" I've replaced most of EmptyNavigableMap/Set with instances of Collections.unmodifiableMap/Set(new TreeMap/Set). The number of classes is smaller and serialization considerations for both now and future backwards compatibility are simpler. Also, since the implementation now largely depends upon TreeMap/TreeSet for getting the subMap/Set bounds issues right it's a lot more likely to be error free.

http://cr.openjdk.java.net/~mduigou/JDK-7129185/4/webrev/

On Jun 12 2013, at 11:49 , Martin Buchholz wrote:
> Thanks for doing this.  Arguably, I or Josh or Doug should have done this for jdk6.  It's tedious to get all the details right.

I am very grateful that some work was left undone for me to do. ;-)

> Mostly looks good.
> 
> I suspect the set returned by emptySortedSet is not serialization-compatible between jdk8 and previous jdks.
emptySortedSet() was added in an earlier Java 8 changeset (JDK-4533691, http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f2f56ac8b82). There is thankfully no backwards compatibility to previous JDK versions though early adopters of JDK 8 will unfortunately encounter serialization compatibility issues as a result of the changes in 7129185

Wanting to get this all finished in the Java 8 iteration is a key motivator.
> Extending EmptySortedSet to also implement NavigableSet ought to be both more compatible and more efficient.  And more tedious!
This shouldn't be necessary since EmptySortedSet appeared in Java 8

> The code fragment below doesn't actually work, cuz WeakHashMap is not a NavigableMap.
Good point. I tried redoing this using a Collections.checkedNavigableMap(new TreeMap()) but quickly decided instead that...
> It's traditional to only @link to a particular destination once per javadoc block.
> +     * any {@link NavigableMap} implementation.  There is no need to use this
> +     * method on a {@link NavigableMap} implementation that already has a
Since both of the NavigableMap implementations in JDK provide NavigableSet implementations this method is not needed. I had created this class as an intermediate step in earlier refactoring but now conclude that it's not needed. I am removing it. If anyone can think of a good reason to include it, please speak now.


Mike

> 
> On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou  wrote:
> I've done some further updates based upon feedback. I believe this is now "done" and ready for final review.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/
> 
> I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods.
> 
> Mike
> 
> 
> On Jun 7 2013, at 10:58 , Mike Duigou wrote:
> 
> > Hello all;
> >
> > I've incorporated feedback from previous rounds and expect to finalize this addition soon.
> >
> > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/
> >
> > Any review feedback or suggestions of additional tests welcome.
> >
> > Thanks,
> >
> > Mike
> >
> >
> 
> 



From forax at univ-mlv.fr  Fri Jun 14 23:37:40 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 15 Jun 2013 01:37:40 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
Message-ID: <51BBA944.9050905@univ-mlv.fr>

On 06/14/2013 11:57 PM, Mike Duigou wrote:
> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
>
> For interference detection the strategy I am advocating is :
>
> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.

I don't think this corner case worth to spend more bits in replies, I'm 
Ok with your arguments ... but because I love to have the last word, 
could you put superior between quotes :)

>
> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.

yes

>
> Mike

R?mi

>
> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
>
>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>
>> Revised webrev:
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>
>> Mike
>>
>>
>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>
>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>> Hello all;
>>>>
>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>
>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>
>>>> Mike
>>> Hi Mike,
>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>
>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>> so you can not do a modCount check only at the end.
>>>
>>> R?mi
>>>
>>> Here is the diff.
>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -28,6 +28,7 @@
>>> import java.io.*;
>>> import java.lang.reflect.ParameterizedType;
>>> import java.lang.reflect.Type;
>>> +import java.util.function.BiConsumer;
>>> import java.util.function.Consumer;
>>> import java.util.function.BiFunction;
>>> import java.util.function.Function;
>>> @@ -2615,6 +2616,54 @@
>>>     int   capacity()     { return table.length; }
>>>     float loadFactor()   { return loadFactor;   }
>>>
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        final int expectedModCount = modCount;
>>> +        if (nullKeyEntry != null) {
>>> +            forEachNullKey(expectedModCount, action);
>>> +        }
>>> +        Object[] table = this.table;
>>> +        for(int index = 0; index < table.length; index++) {
>>> +            Object item = table[index];
>>> +            if (item == null) {
>>> +                continue;
>>> +            }
>>> +            if (item instanceof HashMap.TreeBin) {
>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>> +                continue;
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)item;
>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>> +                if (expectedModCount != modCount) {
>>> +                    throw new ConcurrentModificationException();
>>> +                }
>>> +                action.accept(entry.key, entry.value);
>>> +            }
>>> +        }
>>> +    }
>>> +
>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>> +        while (node != null) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)node.entry;
>>> +            action.accept(entry.key, entry.value);
>>> +            node = (TreeNode)entry.next;
>>> +        }
>>> +    }
>>> +
>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>> +        if (expectedModCount != modCount) {
>>> +            throw new ConcurrentModificationException();
>>> +        }
>>> +        action.accept(null, nullKeyEntry.value);
>>> +    }
>>> +
>>>     /**
>>>      * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>      */
>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -24,7 +24,8 @@
>>> */
>>>
>>> package java.util;
>>> -import java.io.*;
>>> +
>>> +import java.util.function.BiConsumer;
>>>
>>> /**
>>> * 
    Hash table and linked list implementation of the Map interface,
>>> @@ -470,4 +471,16 @@
>>>     protected boolean removeEldestEntry(Map.Entry eldest) {
>>>         return false;
>>>     }
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        int expectedModCount = modCount;
>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            action.accept(entry.key, entry.value);
>>> +        }
>>> +    }
>>> }
>>>
>>>



From rob.mckenna at oracle.com  Sat Jun 15 00:28:16 2013
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Sat, 15 Jun 2013 01:28:16 +0100
Subject: 8016701: JAXP Build failure
Message-ID: <51BBB520.8020902@oracle.com>

Hi folks,

As per the bug:

JAXP must be buildable using JDK7 as the bootdir. Unfortunately 
http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145 calls a method 
that only exists in 8. (Double.isFinite())

This element of the changeset needs to be reverted.

http://cr.openjdk.java.net/~robm/8016701/webrev.01/

Please reply-all when responding to this mail as Brad would like to stay 
on board.

     -Rob



From joe.darcy at oracle.com  Sat Jun 15 00:31:40 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 14 Jun 2013 17:31:40 -0700
Subject: 8016701: JAXP Build failure
In-Reply-To: <51BBB520.8020902@oracle.com>
References: <51BBB520.8020902@oracle.com>
Message-ID: <51BBB5EC.9030105@oracle.com>

Looks fine Rob; approved.

-Joe

On 6/14/2013 5:28 PM, Rob McKenna wrote:
> Hi folks,
>
> As per the bug:
>
> JAXP must be buildable using JDK7 as the bootdir. Unfortunately 
> http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145 calls a 
> method that only exists in 8. (Double.isFinite())
>
> This element of the changeset needs to be reverted.
>
> http://cr.openjdk.java.net/~robm/8016701/webrev.01/
>
> Please reply-all when responding to this mail as Brad would like to 
> stay on board.
>
>     -Rob
>



From bradford.wetmore at oracle.com  Sat Jun 15 00:55:45 2013
From: bradford.wetmore at oracle.com (Brad Wetmore)
Date: Fri, 14 Jun 2013 17:55:45 -0700
Subject: 8016701: JAXP Build failure
In-Reply-To: <51BBB5EC.9030105@oracle.com>
References: <51BBB520.8020902@oracle.com> <51BBB5EC.9030105@oracle.com>
Message-ID: <51BBBB91.70006@oracle.com>

Approved.

Brad


On 6/14/2013 5:31 PM, Joe Darcy wrote:
> Looks fine Rob; approved.
>
> -Joe
>
> On 6/14/2013 5:28 PM, Rob McKenna wrote:
>> Hi folks,
>>
>> As per the bug:
>>
>> JAXP must be buildable using JDK7 as the bootdir. Unfortunately
>> http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145 calls a
>> method that only exists in 8. (Double.isFinite())
>>
>> This element of the changeset needs to be reverted.
>>
>> http://cr.openjdk.java.net/~robm/8016701/webrev.01/
>>
>> Please reply-all when responding to this mail as Brad would like to
>> stay on board.
>>
>>     -Rob
>>
>


From Alan.Bateman at oracle.com  Sat Jun 15 06:41:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Jun 2013 07:41:02 +0100
Subject: 8016701: JAXP Build failure
In-Reply-To: <51BBB520.8020902@oracle.com>
References: <51BBB520.8020902@oracle.com>
Message-ID: <51BC0C7E.9000609@oracle.com>

On 15/06/2013 01:28, Rob McKenna wrote:
> Hi folks,
>
> As per the bug:
>
> JAXP must be buildable using JDK7 as the bootdir. Unfortunately 
> http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145 calls a 
> method that only exists in 8. (Double.isFinite())
>
> This element of the changeset needs to be reverted.
>
> http://cr.openjdk.java.net/~robm/8016701/webrev.01/
>
> Please reply-all when responding to this mail as Brad would like to 
> stay on board.
>
>     -Rob
>
Thanks for jumping on this, looks good.

-Alan


From Alan.Bateman at oracle.com  Sat Jun 15 06:56:49 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Jun 2013 07:56:49 +0100
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51BBA06A.7060106@oracle.com>
References: <51BB9065.4070704@oracle.com> <51BBA06A.7060106@oracle.com>
Message-ID: <51BC1031.3060606@oracle.com>

On 14/06/2013 23:59, Kurchi Hazra wrote:
>
> Hi,
> This is to elimnate the overrides warning from ClassDeclaration.java. 
> This class is used by rmi, but sun/tools/java and
> sun/tools/javac also heavily uses it, let me know if anyone else 
> should also be reviewing it.
>
> Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
> Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/
>
> Thanks,
> Kurchi
This looks okay for the purposes of squashing the warning but the 
existing equals method does look suspect. It might not matter for the 
rmic usage but as the equals doesn't take account of the the 
"definition" then it looks to me that it consider very different 
ClassDeclarations as equals. It would be good to understand how it is 
used to see whether we have an issue here or not.

-Alan


From chris.hegarty at oracle.com  Sat Jun 15 07:01:48 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 15 Jun 2013 08:01:48 +0100
Subject: 8016701: JAXP Build failure
In-Reply-To: <51BBB520.8020902@oracle.com>
References: <51BBB520.8020902@oracle.com>
Message-ID: <51BC115C.5090904@oracle.com>

Thanks Rob, looks fine.

-Chris.

On 15/06/2013 01:28, Rob McKenna wrote:
> Hi folks,
>
> As per the bug:
>
> JAXP must be buildable using JDK7 as the bootdir. Unfortunately
> http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/659828443145 calls a method
> that only exists in 8. (Double.isFinite())
>
> This element of the changeset needs to be reverted.
>
> http://cr.openjdk.java.net/~robm/8016701/webrev.01/
>
> Please reply-all when responding to this mail as Brad would like to stay
> on board.
>
> -Rob
>


From rob.mckenna at oracle.com  Sat Jun 15 08:25:36 2013
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Sat, 15 Jun 2013 08:25:36 +0000
Subject: hg: jdk8/tl/jaxp: 8016701: JAXP Build failure
Message-ID: <20130615082540.28CFB4823A@hg.openjdk.java.net>

Changeset: 2707f600a096
Author:    robm
Date:      2013-06-15 09:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2707f600a096

8016701: JAXP Build failure
Reviewed-by: darcy, wetmore, alanb, chegar

! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java



From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 18:33:39 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 13:33:39 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
Message-ID: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>

Bug 4851444 [1] was filed just over 10 years ago and has languished without so much as a comment ever since. I hate to revive something so old, but I'd like to see what everyone thinks.

I'm working on the Apache project Log4j2. Our problem is we need to get the Class object that belongs to a particular element on the stack trace. We use three different methods, failing over from one to the next, in order to get the Class object.

1. If sun.reflect.Reflection#getCallerClass(int) exists, we repeatedly call it--increasing the depth each time--to fill up a java.util.Stack, then compare it to the exception stack trace and match as many of the elements as we can to Classes returned by getCallerClass. This is surprisingly fast, but some elements don't match and we have to fail over to 3.

2. If sun.reflect.Reflection.getCallerClass(int) does not exist, we create a SecurityManager and call getClassContext(), use it to fill up a java.util.Stack, and do the same thing we would normally do with 1. This is about two times slower than 1--not terrible.

3. If the element in a stack trace doesn't match a class found in methods 1 or 2, we load the class with the ClassLoader using the class name in the StackTraceElement. This is more than TEN TIMES SLOWER than 1--terrible.

As you can see, it greatly benefits us to have some kind of efficient mechanism to match a StackTraceElement to a Class, so that's why we resort to using a non-public API (with the understanding that we must have backup options since this class will not always be present).

Where I came in is when the change was made in 1.8.0-ea-b87 to remove the parameter from sun.reflect.Reflection#getCallerClass(). Now getCallerClass() can ONLY be used to retrieve the immediate caller, not callers at various depth, making method 1 unusable in Java 8. This led me to look for an alternative.

Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement calls CVMgetStackTraceElement. 
CVMgetStackTraceElement, in turn, then gets a copy of the native version of the Class object and uses it to populate the StackTraceElement's data. This leads me to believe that the task of adding a getElementClass() method to StackTraceElement would be as simple as:

1) Adding a new constructor to StackTraceElement to preserve backwards compatibility, with the Class being null by default.
2) Add the getStackTraceElement() method and backing private field.
3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.

I'm sure there are some idiosyncrasies I'm missing here, but overall this seems like a pretty trivial change. What do people think? Can this be worked in? .NET has had this ability since .NET 1.1 with the StackFrame class [2] and the StackTrace [3], which contains StackFrames. It provides more than just the Class (Type in .NET), it also provides the Method (MethodBase in .NET). It would greatly improve the efficiency of certain tasks not only in Log4j, but also in many other projects that I have found using getCallerClass() for the same purpose.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444
[2] http://msdn.microsoft.com/en-us/library/system.diagnostics.stackframe.aspx
[3] http://msdn.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx



From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 18:34:58 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 13:34:58 -0500
Subject: There needs to be support for java.time in java.text.MessageFormat
Message-ID: 

Currently, MessageFormat /only/ supports SimpleDateFormat and instances of java.util.Date or java.util.Calendar for date/time values. Because of this, it's impossible to use Java 8 date/time types with any of the i18n and localization tools.

MessageFormat really needs support for types in java.time. Should I file a bug somewhere about this (where?), or is this message enough to get this going? I'm not even sure how it should work. I'm not sure how MessageFormat can know whether a SimpleDateFormat string or a DateTimeFormatter string is being supplied. Possibly, validation of the format string must be delayed until either a Date/Calendar or a java.time type is supplied for formatting.

From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 19:04:26 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 14:04:26 -0500
Subject: Java 8 has type annotations now;
	perfect time to add bug detection annotations
Message-ID: 

One of the many reasons for JSR-308 type annotations (as I understand it) was to improve support for static code analyzers. The additional places that annotations can be placed now allows static code analyzers to more accurately assess code for potential bugs, such as NPEs.

However, the various tools out there (FindBugs, IntelliJ IDEA, and more) all provide their own set of annotations to support such analysis, and there are a few problems with this:

1) In order to take advantage of type annotations, these tools will have to provide two versions of their annotation libraries: a Java 8 version with ElementType.TYPE_USE and ElementType.TYPE_PARAMETER, and a Java < 8 version without these.

2) This isn't portable. As a developer of an application, if I decide I need to change static code analyzers for some reason, I have to change all of my annotations.

3) As a consumer of other libraries that have used annotations for this purpose, I likely have to use the same static code analyzer they do in order for their annotations to be useful when my application is being analyzed.

JSR-305 ("Annotations for Software Defect Detection") was created for just this purpose. It was supposed to define a set of annotations that could be relied on universally to support software defect detection. Unfortunately, it eventually became dormant. I'd love to see the following:

1) The JSR revived (this is outside the scope of this mailing list, I know; I may try to join the expert group to revive it).

2) The annotations defined in the JSR added to Java SE 8 (this is where this mailing list comes in).

3) A separate, standalone JAR of these annotations (minus ElementType.TYPE_USE and ElementType.TYPE_PARAMETER) that can be used in Java 6 and 7 libraries and applications.

What's the best way to proceed with this and make this happen? I'm not suggesting a major functional change or a change to the language spec; I'm just talking about putting a bunch of annotations in the core libs that don't do anything by themselves without static code analysis tools like FindBugs.

Nick

From forax at univ-mlv.fr  Sat Jun 15 19:22:09 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 15 Jun 2013 21:22:09 +0200
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
Message-ID: <51BCBEE1.4040300@univ-mlv.fr>

On 06/15/2013 08:33 PM, Nick Williams wrote:
> Bug 4851444 [1] was filed just over 10 years ago and has languished without so much as a comment ever since. I hate to revive something so old, but I'd like to see what everyone thinks.

Hi Nick,
first 4851444 should be closed in my opinion, given that 1.6 introduces 
the ServiceLoader class which is the way to load implementation of a 
service.
JAXP and JAXB now use the ServiceLoader.

Could you be a little more clear why you need a class for your logging 
API, exactly, why the class name is not enough for logging purpose ?

And about adding a way to store the class in the StackTraceElement, one 
issue is that stack trace element are Serializable, so if an error 
occurs on a server, the exception can be serialized to the client which 
is a really nice feature, but if a stack trace element embed the class 
object, then it means that all the class that are available at server 
side should also be available at client side.
I have no idea how Microsoft solve this issue.

cheers,
R?mi

>
> I'm working on the Apache project Log4j2. Our problem is we need to get the Class object that belongs to a particular element on the stack trace. We use three different methods, failing over from one to the next, in order to get the Class object.
>
> 1. If sun.reflect.Reflection#getCallerClass(int) exists, we repeatedly call it--increasing the depth each time--to fill up a java.util.Stack, then compare it to the exception stack trace and match as many of the elements as we can to Classes returned by getCallerClass. This is surprisingly fast, but some elements don't match and we have to fail over to 3.
>
> 2. If sun.reflect.Reflection.getCallerClass(int) does not exist, we create a SecurityManager and call getClassContext(), use it to fill up a java.util.Stack, and do the same thing we would normally do with 1. This is about two times slower than 1--not terrible.
>
> 3. If the element in a stack trace doesn't match a class found in methods 1 or 2, we load the class with the ClassLoader using the class name in the StackTraceElement. This is more than TEN TIMES SLOWER than 1--terrible.
>
> As you can see, it greatly benefits us to have some kind of efficient mechanism to match a StackTraceElement to a Class, so that's why we resort to using a non-public API (with the understanding that we must have backup options since this class will not always be present).
>
> Where I came in is when the change was made in 1.8.0-ea-b87 to remove the parameter from sun.reflect.Reflection#getCallerClass(). Now getCallerClass() can ONLY be used to retrieve the immediate caller, not callers at various depth, making method 1 unusable in Java 8. This led me to look for an alternative.
>
> Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement calls CVMgetStackTraceElement.
> CVMgetStackTraceElement, in turn, then gets a copy of the native version of the Class object and uses it to populate the StackTraceElement's data. This leads me to believe that the task of adding a getElementClass() method to StackTraceElement would be as simple as:
>
> 1) Adding a new constructor to StackTraceElement to preserve backwards compatibility, with the Class being null by default.
> 2) Add the getStackTraceElement() method and backing private field.
> 3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.
>
> I'm sure there are some idiosyncrasies I'm missing here, but overall this seems like a pretty trivial change. What do people think? Can this be worked in? .NET has had this ability since .NET 1.1 with the StackFrame class [2] and the StackTrace [3], which contains StackFrames. It provides more than just the Class (Type in .NET), it also provides the Method (MethodBase in .NET). It would greatly improve the efficiency of certain tasks not only in Log4j, but also in many other projects that I have found using getCallerClass() for the same purpose.
>
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444
> [2] http://msdn.microsoft.com/en-us/library/system.diagnostics.stackframe.aspx
> [3] http://msdn.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx
>



From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 19:59:02 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 14:59:02 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <51BCBEE1.4040300@univ-mlv.fr>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCBEE1.4040300@univ-mlv.fr>
Message-ID: <06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>


On Jun 15, 2013, at 2:22 PM, Remi Forax wrote:

> On 06/15/2013 08:33 PM, Nick Williams wrote:
>> Bug 4851444 [1] was filed just over 10 years ago and has languished without so much as a comment ever since. I hate to revive something so old, but I'd like to see what everyone thinks.
> 
> Hi Nick,
> first 4851444 should be closed in my opinion, given that 1.6 introduces the ServiceLoader class which is the way to load implementation of a service.
> JAXP and JAXB now use the ServiceLoader.

There are really two parts to this bug: what the user needed to accomplish (which ServiceLoader accomplishes), and the suggestion for exposing getCallerClass() (which has broader implications than just his particular use-case).

> 
> Could you be a little more clear why you need a class for your logging API, exactly, why the class name is not enough for logging purpose ?

Certainly. Log4j 2 offers "extended stack trace" patterns. When exceptions or stack traces are logged, or when displaying the location that the logging statement originated from, the stack trace/log also reveals the resource (JAR file, directory, etc.) that the class was loaded from and the implementation version from the package the class is in. This helps reveal possible class loading issues (among other things), which can be an extremely valuable tool when troubleshooting problems with an application.

Log4j 2 accomplishes this by getting the class associated with a StackTraceElement (as outlined below), and then 1) getting the Package from the Class and the version from the Package, and 2) getting the ProtectionDomain from the Class, getting the CodeSource from the ProtectionDomain, and getting the JAR/URL from the CodeSource. The last two parts are easy. It's getting the Class from the StackTrace that is extremely inefficient if not done right. Java 8 took away the best way we had found to do that (which, admittedly, was because we were relying on a non-standard class, which isn't recommended).

> 
> And about adding a way to store the class in the StackTraceElement, one issue is that stack trace element are Serializable, so if an error occurs on a server, the exception can be serialized to the client which is a really nice feature, but if a stack trace element embed the class object, then it means that all the class that are available at server side should also be available at client side.
> I have no idea how Microsoft solve this issue.

Classes are Serializable in Java, so it shouldn't cause a problem with serialization. The elementClass property will be properly serialized and deserialized. If I understand you correctly, you're expressing concern that this could actually be a problem; that we don't want Classes transferred to the client and deserialized. The Class class has a special serialized form that is unlike other classes and is very efficient. Only a descriptor for the class (including its serialVersionUID value) is transmitted, just enough to give the endpoint enough information to locate the class. There won't be a performance issue here, as far as I can tell. However, I can foresee one potential problem when deserializing the StackTraceElement: if the Class isn't on the class path on the deserializing JVM. This could be handled two possible ways:

1) Mark the elementClass property on StackTraceElement transient so that it isn't serialized.
2) Add a special deserialization rule (not unprecedented by any means) for StackTraceElement that says that StackTraceElement will not fail to deserialize if the elementClass property can't be deserialized because it couldn't be loaded. (This would be my suggestion.)

I'm not sure how .NET handles it either, but it clearly does, as its StackFrame class is the equivalent of Serializable.

Nick

> 
> cheers,
> R?mi
> 
>> 
>> I'm working on the Apache project Log4j2. Our problem is we need to get the Class object that belongs to a particular element on the stack trace. We use three different methods, failing over from one to the next, in order to get the Class object.
>> 
>> 1. If sun.reflect.Reflection#getCallerClass(int) exists, we repeatedly call it--increasing the depth each time--to fill up a java.util.Stack, then compare it to the exception stack trace and match as many of the elements as we can to Classes returned by getCallerClass. This is surprisingly fast, but some elements don't match and we have to fail over to 3.
>> 
>> 2. If sun.reflect.Reflection.getCallerClass(int) does not exist, we create a SecurityManager and call getClassContext(), use it to fill up a java.util.Stack, and do the same thing we would normally do with 1. This is about two times slower than 1--not terrible.
>> 
>> 3. If the element in a stack trace doesn't match a class found in methods 1 or 2, we load the class with the ClassLoader using the class name in the StackTraceElement. This is more than TEN TIMES SLOWER than 1--terrible.
>> 
>> As you can see, it greatly benefits us to have some kind of efficient mechanism to match a StackTraceElement to a Class, so that's why we resort to using a non-public API (with the understanding that we must have backup options since this class will not always be present).
>> 
>> Where I came in is when the change was made in 1.8.0-ea-b87 to remove the parameter from sun.reflect.Reflection#getCallerClass(). Now getCallerClass() can ONLY be used to retrieve the immediate caller, not callers at various depth, making method 1 unusable in Java 8. This led me to look for an alternative.
>> 
>> Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement calls CVMgetStackTraceElement.
>> CVMgetStackTraceElement, in turn, then gets a copy of the native version of the Class object and uses it to populate the StackTraceElement's data. This leads me to believe that the task of adding a getElementClass() method to StackTraceElement would be as simple as:
>> 
>> 1) Adding a new constructor to StackTraceElement to preserve backwards compatibility, with the Class being null by default.
>> 2) Add the getStackTraceElement() method and backing private field.
>> 3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.
>> 
>> I'm sure there are some idiosyncrasies I'm missing here, but overall this seems like a pretty trivial change. What do people think? Can this be worked in? .NET has had this ability since .NET 1.1 with the StackFrame class [2] and the StackTrace [3], which contains StackFrames. It provides more than just the Class (Type in .NET), it also provides the Method (MethodBase in .NET). It would greatly improve the efficiency of certain tasks not only in Log4j, but also in many other projects that I have found using getCallerClass() for the same purpose.
>> 
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444
>> [2] http://msdn.microsoft.com/en-us/library/system.diagnostics.stackframe.aspx
>> [3] http://msdn.microsoft.com/en-us/library/system.diagnostics.stacktrace.aspx
>> 
> 



From Alan.Bateman at oracle.com  Sat Jun 15 20:21:29 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 15 Jun 2013 21:21:29 +0100
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
Message-ID: <51BCCCC9.2080208@oracle.com>

On 15/06/2013 19:33, Nick Williams wrote:
> :
>
> Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement calls CVMgetStackTraceElement.
> CVMgetStackTraceElement, in turn, then gets a copy of the native version of the Class object and uses it to populate the StackTraceElement's data. This leads me to believe that the task of adding a getElementClass() method to StackTraceElement would be as simple as:
>
> 1) Adding a new constructor to StackTraceElement to preserve backwards compatibility, with the Class being null by default.
> 2) Add the getStackTraceElement() method and backing private field.
> 3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.
>
> I'm sure there are some idiosyncrasies I'm missing here, but overall this seems like a pretty trivial change. What do people think? Can this be worked in? .NET has had this ability since .NET 1.1 with the StackFrame class [2] and the StackTrace [3], which contains StackFrames. It provides more than just the Class (Type in .NET), it also provides the Method (MethodBase in .NET). It would greatly improve the efficiency of certain tasks not only in Log4j, but also in many other projects that I have found using getCallerClass() for the same purpose.
>
Here's a discussion from last year on this topic:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011665.html

-Alan.


From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 21:06:50 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 16:06:50 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <51BCCCC9.2080208@oracle.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
Message-ID: 


On Jun 15, 2013, at 3:21 PM, Alan Bateman wrote:

> On 15/06/2013 19:33, Nick Williams wrote:
>> :
>> 
>> Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement calls CVMgetStackTraceElement.
>> CVMgetStackTraceElement, in turn, then gets a copy of the native version of the Class object and uses it to populate the StackTraceElement's data. This leads me to believe that the task of adding a getElementClass() method to StackTraceElement would be as simple as:
>> 
>> 1) Adding a new constructor to StackTraceElement to preserve backwards compatibility, with the Class being null by default.
>> 2) Add the getStackTraceElement() method and backing private field.
>> 3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.
>> 
>> I'm sure there are some idiosyncrasies I'm missing here, but overall this seems like a pretty trivial change. What do people think? Can this be worked in? .NET has had this ability since .NET 1.1 with the StackFrame class [2] and the StackTrace [3], which contains StackFrames. It provides more than just the Class (Type in .NET), it also provides the Method (MethodBase in .NET). It would greatly improve the efficiency of certain tasks not only in Log4j, but also in many other projects that I have found using getCallerClass() for the same purpose.
>> 
> Here's a discussion from last year on this topic:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011665.html
> 
> -Alan.

Indeed. Looks like the discussion died somewhat after a while. No conclusion was ever made. Based on the discussion it the email, I would add some additional observations/behavior that I think should be considered:

1) The elementClass property (getElementClass method) should be the Class that matches StackTraceElement's className property. It should not be the type of the object that received the method invocation. Perhaps, then, it would be better to call it frameClass (getFrameClass), to make it more obvious that it's the class for the frame on the stack.

2) If elementClass is made to be the type of the object that received the method invocation, then an getMethod() method should also be added so that the Class that defined the method that was executed can be obtained. This might actually be the most versatile option. However, Method is not Serializable, so that must then be considered.

3) I'm okay with making the elementClass transient. I don't have a particular need for it to be serialized, and making it transient is the easiest way to solve some problems.

4) Vitaly's email said that StackFrame exposes the MethodBase (Method), but not the Type (Class). This is correct. I wasn't clear on this earlier. To get the frame Type you would use stackFrameInstance.GetMethod().DeclaringType.

5) I do think the elementClass (or whatever) property should be Weak. If a particular piece of code (foolishly) hangs on to a StackTraceElement instance, it could cause a ClassLoader memory leak, particularly in Java EE containers. Making it Weak is the safest approach. Existing code written for earlier versions of Java may hang on to StackTraceElements for whatever reason, and problems wouldn't begin to arise from that until the code was run on Java 8.

6) I don't think security is a major issue here. There's not a lot you can do with a Class instance without involving existing security checks. For example, you can inspect the Class's name, Package, CodeSource, etc., but you can't invoke methods, manipulate fields, or create an instance of the Class without security checks being performed. Let's consider three possible scenarios:

A) A Class loaded by a parent class loader obtains a StackTraceElement containing Classes loaded by a child class loader. I don't see a major issue here. The obvious scenario is a library loaded by a Servlet container obtaining a Class loaded within one of the web application class loaders. It's much more likely that this code will be "well behaved" and already has some kind of power over the child class loader anyway.

B) A Class loaded by a child class loader obtains a StackTraceElement containing Classes loaded by a sibling class loader. This would obviously be the more dangerous scenario (think: one web application accessing another web application's classes), but I don't think it's actually possible. I don't think a stack trace generated in one class loader can possibly make its way into code in a sibling class loader, and I know that an execution stack can't contain classes from two sibling class loaders (only from class loaders with parent/child relationships).

C) A Class loaded by a child class loader obtains a StackTraceElement containing Classes loaded by a parent class loader. There's no issue here. Child class loaders can already access classes from their parent class loaders.

I'd love for the conversation started in the original thread (that Alan pointed out) to pick up here and come to some kind of resolution. I think this could be a big help to developers, especially those creating diagnostic tools (like logging frameworks).

Nick

From peter.levart at gmail.com  Sat Jun 15 21:43:34 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 15 Jun 2013 23:43:34 +0200
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCBEE1.4040300@univ-mlv.fr>
	<06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>
Message-ID: <51BCE006.2080308@gmail.com>


On 06/15/2013 09:59 PM, Nick Williams wrote:
>> And about adding a way to store the class in the StackTraceElement, one issue is that stack trace element are Serializable, so if an error occurs on a server, the exception can be serialized to the client which is a really nice feature, but if a stack trace element embed the class object, then it means that all the class that are available at server side should also be available at client side.
>> >I have no idea how Microsoft solve this issue.
> Classes are Serializable in Java, so it shouldn't cause a problem with serialization. The elementClass property will be properly serialized and deserialized. If I understand you correctly, you're expressing concern that this could actually be a problem; that we don't want Classes transferred to the client and deserialized. The Class class has a special serialized form that is unlike other classes and is very efficient. Only a descriptor for the class (including its serialVersionUID value) is transmitted, just enough to give the endpoint enough information to locate the class.

That's true when  Class objects are serialized with a purpose and intent 
that they will be deserialized in an environment where correct versions 
of those classes are visible by class initiating deserialization. Stack 
trace can contain references to classes that are not visible even by the 
class that constructed the Throwable. By exposing Class objects that 
would otherwise not be obtainable, there could be security issues.

> There won't be a performance issue here, as far as I can tell. However, I can foresee one potential problem when deserializing the StackTraceElement: if the Class isn't on the class path on the deserializing JVM. This could be handled two possible ways:
>
> 1) Mark the elementClass property on StackTraceElement transient so that it isn't serialized.
> 2) Add a special deserialization rule (not unprecedented by any means) for StackTraceElement that says that StackTraceElement will not fail to deserialize if the elementClass property can't be deserialized because it couldn't be loaded. (This would be my suggestion.)
>
> I'm not sure how .NET handles it either, but it clearly does, as its StackFrame class is the equivalent of Serializable.

I think that option #1 is the only realistic option. Who cares about 
classes in the de-serialized stack-trace. The only thing needed is their 
names so that the stack-trace can be printed.

Regards, Peter






From peter.levart at gmail.com  Sat Jun 15 22:05:13 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 16 Jun 2013 00:05:13 +0200
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: 
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
Message-ID: <51BCE519.3050009@gmail.com>


On 06/15/2013 11:06 PM, Nick Williams wrote:
> B) A Class loaded by a child class loader obtains a StackTraceElement containing Classes loaded by a sibling class loader. This would obviously be the more dangerous scenario (think: one web application accessing another web application's classes), but I don't think it's actually possible. I don't think a stack trace generated in one class loader can possibly make its way into code in a sibling class loader, and I know that an execution stack can't contain classes from two sibling class loaders (only from class loaders with parent/child relationships).

Why not?  Consider this hypothetical code:

Parent class loader:

     public class A {
         public static final A INSTANCE = new A();
         final PropertyChangeSupport pcs = new PropertyChangeSupport(this);
         public void addPropertyChangeListener(PropertyChangeListener 
pcl) { pcs.addPropertyChangeListener(pcl); }
         String property;
         public void setProperty(String property) {
             pcs.firePropertyChange("property", this.property, 
this.property = property);
         }
     }

Child class loader 1:

     static class B implements PropertyChangeListener {
         B() {
             A a = A.INSTANCE;
             a.addPropertyChangeListener(this);
         }

         @Override
         public void propertyChange(PropertyChangeEvent evt) {
             StackTraceElement[] st = new Throwable().getStackTrace();
             // can we see C.class in 'st' array?
         }
     }

Child class loader 2:

     static class C {
         void m() {
             A a = A.INSTANCE;
             a.setProperty("XYZ");
         }
     }



Regards, Peter



From nicholas+openjdk at nicholaswilliams.net  Sat Jun 15 22:36:26 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sat, 15 Jun 2013 17:36:26 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <51BCE519.3050009@gmail.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
Message-ID: 


On Jun 15, 2013, at 5:05 PM, Peter Levart wrote:

> 
> On 06/15/2013 11:06 PM, Nick Williams wrote:
>> B) A Class loaded by a child class loader obtains a StackTraceElement containing Classes loaded by a sibling class loader. This would obviously be the more dangerous scenario (think: one web application accessing another web application's classes), but I don't think it's actually possible. I don't think a stack trace generated in one class loader can possibly make its way into code in a sibling class loader, and I know that an execution stack can't contain classes from two sibling class loaders (only from class loaders with parent/child relationships).
> 
> Why not?  Consider this hypothetical code:
> 
> Parent class loader:
> 
>     public class A {
>         public static final A INSTANCE = new A();
>         final PropertyChangeSupport pcs = new PropertyChangeSupport(this);
>         public void addPropertyChangeListener(PropertyChangeListener pcl) { pcs.addPropertyChangeListener(pcl); }
>         String property;
>         public void setProperty(String property) {
>             pcs.firePropertyChange("property", this.property, this.property = property);
>         }
>     }
> 
> Child class loader 1:
> 
>     static class B implements PropertyChangeListener {
>         B() {
>             A a = A.INSTANCE;
>             a.addPropertyChangeListener(this);
>         }
> 
>         @Override
>         public void propertyChange(PropertyChangeEvent evt) {
>             StackTraceElement[] st = new Throwable().getStackTrace();
>             // can we see C.class in 'st' array?
>         }
>     }
> 
> Child class loader 2:
> 
>     static class C {
>         void m() {
>             A a = A.INSTANCE;
>             a.setProperty("XYZ");
>         }
>     }
> 
> 
> 
> Regards, Peter

Huh. An interesting quandary. And definitely not desirable...

The first thing I would say is that the code you suggest isn't, in my opinion, "responsible" code, and in fact is dangerous. I know some guys over on the Tomcat mailing list that would possibly shriek in terror if they saw code like this. If an application server (parent class loader) had a class like A that allowed actions of one web application (class C) to trigger method calls in another web application (class B), nightmarish things would happen. In actuality, class A should have different contexts for different class loaders. If you write code like this and allow it to be used across sibling class loaders in this manner, you are asking for more trouble than you're going to get merely by having a Class instance in the StackTraceElement.

In fact, DriverManager is a perfect example. If a web application loads a JDBC driver from its WEB-INF/lib, that driver will immediately become visible to other web applications, and it will cause a memory leak. There was a recent discussion about this on the Tomcat mailing list, and the general tenor was "DriverManager is hopelessly broken, don't put drivers there, they can only safely go in the container's class loader." I could argue that DriverManager has already created the very security issue that you propose exists by added a Class instance to the StackTraceElement, but that by itself doesn't make it OK (broken window syndrome/broken windows theory).

Still, in the scenario you propose there could be bigger security consequences than merely having an instance of Class in StackTraceElement. What if setProperty() takes an Object instead of a String (class loader leak). MOST IMPORTANTLY: What if class B extends SecurityManager, instantiates it (but doesn't install it), and calls SecurityManager#getClassContext() from B#propertyChange(). The getClassContext() method essential returns the stack trace of Classes instead of StackTraceElements.

I'm going to stick by my original assessment that I'm not convinced there's a security issue. It's possible that getClassContext() filters out classes the caller can't access, but nothing in the documentation indicates that's the case, so I'm operating under the assumption that it doesn't. If I'm right, there's no harm in StackTraceElement also having a Class instance. But understand getClassContext() does not fulfill my use case entirely. I need the Classes in a stack trace created when an exception is thrown, too, and getClassContext() only gives me those classes in my current executing stack.

Nick



From henry.jen at oracle.com  Sat Jun 15 23:27:09 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Sat, 15 Jun 2013 16:27:09 -0700
Subject: RFR 8009736: Comparator API cleanup
In-Reply-To: 
References: <51B790E6.6020209@oracle.com>
	
Message-ID: <51BCF84D.6050408@oracle.com>

On 06/14/2013 10:10 AM, Jason Mehrens wrote:
> Any chance the static method Comparator.reverseOrder()  will be renamed
> to something like reversedNaturalOrder?  Now all of the calls to
> Comparator.reverseOrder() take on new meaning.
>  

I feel that it's inconvenient for early adapters, but this is still the
new API in 8 and we should still choose the best name.

reverseOrder() is a natural choice and just a migration from Comparators.

The old reverseOrder() is an instance default method, and is a
compromise of reverse() for name clashing, I think reversed() is the
right name.

As the renaming of that default method is necessary, I think it's just
need more attention on find out all method calls. The difference between
a static and default method can be used to hint on search in files.

Cheers,
Henry





From henry.jen at oracle.com  Sat Jun 15 23:28:54 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Sat, 15 Jun 2013 16:28:54 -0700
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51B790E6.6020209@oracle.com>
References: <51B790E6.6020209@oracle.com>
Message-ID: <51BCF8B6.4050307@oracle.com>

Reflecting feedbacks received so far, please see

http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/webrev/
http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/specdiff

Cheers,
Henry


On 06/11/2013 02:04 PM, Henry Jen wrote:
> Hi,
> 
> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
> 
> Highlight of changes,
> 
> - Comparators class is now only package-private implementations. The
> public static methods have been move to other arguably more appropriate
> places, mostly in Comparator.
> 
> - Comparator.reverseOrder() is renamed to Comparator.reversed()
> 
> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
> wrap up a comparator to be null-friendly.
> 
> To see the API changes, found the specdiff at
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
> 
> Cheers,
> Henry
> 



From jeroen at sumatra.nl  Sun Jun 16 06:25:25 2013
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Sun, 16 Jun 2013 06:25:25 +0000
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: 
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
Message-ID: <19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>

Nick Williams wrote:
> I'm going to stick by my original assessment that I'm not convinced
> there's a security issue. It's possible that getClassContext() filters
> out classes the caller can't access, but nothing in the documentation
> indicates that's the case, so I'm operating under the assumption that it
> doesn't.

SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument.

Given the security implications, the serialization issue and the need for weak references, it seems to me that adding this to Throwable would be way too expensive. 

Adding a new API to collect a stack trace seems like a far better approach.

Here's my off the cuff proposal:

public final class StackFrame {
  public Executable method();
  public String getFileName();
  public int getLineNumber();

  public static StackFrame[] capture(int skipFrames, int maxLength, boolean includeSourceInfo);
}

Regards,
Jeroen



From mailforanubhav at gmail.com  Sun Jun 16 10:53:49 2013
From: mailforanubhav at gmail.com (Anubhav Chaturvedi)
Date: Sun, 16 Jun 2013 16:23:49 +0530
Subject: Inefficient code of String.indexOf(String)
Message-ID: 

Hello,

I have recently started to explore the source code and am new to the open
source community. I observed that in String.class within java.lang , the
indexOf method, line 1715, uses the bruteforce approach when it comes to
string matching. This method is used by the contains(CharSequence) method.
There are a number of algorithms that can perform the task more efficiently.

I would like to bring the required changes and needed your advice on this.

-- 
*Regards,*
*Anubhav Chaturvedi*

*Birla Institute of Technology & Science, Pilani*
KK Birla Goa Campus
+91-9637399150


From Alan.Bateman at oracle.com  Sun Jun 16 12:59:40 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Jun 2013 13:59:40 +0100
Subject: Inefficient code of String.indexOf(String)
In-Reply-To: 
References: 
Message-ID: <51BDB6BC.8060904@oracle.com>

On 16/06/2013 11:53, Anubhav Chaturvedi wrote:
> Hello,
>
> I have recently started to explore the source code and am new to the open
> source community. I observed that in String.class within java.lang , the
> indexOf method, line 1715, uses the bruteforce approach when it comes to
> string matching. This method is used by the contains(CharSequence) method.
> There are a number of algorithms that can perform the task more efficiently.
>
> I would like to bring the required changes and needed your advice on this.
>
The "How to contribute" page [1] is a good start to understand how to 
contribute changes.

In general, I think it's fair to say that we want the JDK to use the 
best-in-class algorithms and implementations (and there is always things 
to improve).

On String.indexOf then it I has an intrinic implementation in HotSpot 
(at least in the server VM) so you may have to disable that in order to 
test and compare alternative implementations. There is string matching 
in the regex code (java.util.regex.Pattern) where Boyer-Moore is used, 
that might be interesting to look at too.

-Alan

[1] http://openjdk.java.net/contribute/


From aleksey.shipilev at oracle.com  Sun Jun 16 13:20:57 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sun, 16 Jun 2013 17:20:57 +0400
Subject: Inefficient code of String.indexOf(String)
In-Reply-To: 
References: 
Message-ID: <56B79598-04C2-4FC1-943E-04597DB8A214@oracle.com>

Hi Anubhav,

On 16.06.2013, at 14:53, Anubhav Chaturvedi  wrote:
> I would like to bring the required changes and needed your advice on this.

Welcome to OpenJDK!

Please read through OpenJDK contributors page for the process we follow:
   http://openjdk.java.net/contribute/

It would be great if you do additional tests for the code you are bringing in, since whitebox testing might catch more things in addition to standard testing. 

Since your change is the performance one, we recommend to use JMH to build appropriate performance benchmarks:
   http://openjdk.java.net/projects/code-tools/jmh

Thanks,
-Aleksey

From nicholas+openjdk at nicholaswilliams.net  Sun Jun 16 14:29:58 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sun, 16 Jun 2013 09:29:58 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
Message-ID: 


On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:

> Nick Williams wrote:
>> I'm going to stick by my original assessment that I'm not convinced
>> there's a security issue. It's possible that getClassContext() filters
>> out classes the caller can't access, but nothing in the documentation
>> indicates that's the case, so I'm operating under the assumption that it
>> doesn't.
> 
> SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument.

Can you define what "is not available to unprivileged callers" means a little better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just fine. I took a look at the Java code, and it's native, so there's no check there. (You can't instantiate a SecurityManager unless there's not currently a SecurityManager installed _OR_ the installed SecurityManager allows the creation (installation privilege isn't checked) of another SecurityManager. Is that what you're talking about?) I took a look at the native code, and I don't see anything there that would represent a privilege check that I recognized, but if I understood what you meant a little better I might see where I'm wrong.

> Given the security implications, the serialization issue and the need for weak references, it seems to me that adding this to Throwable would be way too expensive. 

The only expense I'm seeing here is the security implications, and I'm still not convinced that they exist. We have all agreed now that making this transient is okay, and adding the transient keyword to a field only takes 5 seconds. And I certainly don't believe that declaring the field as "WeakReference> elementClass" instead of "Class elementClass" takes more than 30 seconds longer, but maybe I'm missing something, so that's not expensive either.

Also, to be clear, I'm not suggesting adding it to Throwable specifically, I'm suggesting adding it to StackTraceElement (which would apply anywhere that a stack trace is filled in, including Throwable). A stack trace is filled in with one native code method, so updating that method will make this work in Throwable, Thread, and anywhere else that you can get a stack trace. I know this is a nitpicky distinction, but it could be important.

> 
> Adding a new API to collect a stack trace seems like a far better approach.
> 
> Here's my off the cuff proposal:
> 
> public final class StackFrame {
>  public Executable method();
>  public String getFileName();
>  public int getLineNumber();
> 
>  public static StackFrame[] capture(int skipFrames, int maxLength, boolean includeSourceInfo);
> }
> 

I'm not opposed to the StackFrame class as suggested, it just doesn't meet my needs. At all. I can already successfully get this information using the stack trace and getClassContext(), so I wouldn't be compelled to switch. I need to efficiently get the Class from a stack trace generated by a Throwable, which this does not solve. Right now I'm having to resort to getting that Class using inefficient methods.

Nick

From Alan.Bateman at oracle.com  Sun Jun 16 16:42:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Jun 2013 17:42:36 +0100
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: 
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
	
Message-ID: <51BDEAFC.2010102@oracle.com>

On 16/06/2013 15:29, Nick Williams wrote:
> On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
>
>> :
>> SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument.
> Can you define what "is not available to unprivileged callers" means a little better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just fine. I took a look at the Java code, and it's native, so there's no check there. (You can't instantiate a SecurityManager unless there's not currently a SecurityManager installed _OR_ the installed SecurityManager allows the creation (installation privilege isn't checked) of another SecurityManager. Is that what you're talking about?) I took a look at the native code, and I don't see anything there that would represent a privilege check that I recognized, but if I understood what you meant a little better I might see where I'm wrong.
The main thing is that the hack to extend SecurityManager (so that you 
can call the protected getClassContext method) is unlikely to work when 
there is security manager set. I can't tell what environments you have 
tested with but usually it means setting up the security policy so that 
the code base of your library is granted the permission. Even then you 
might still have an issue because there will likely be frames associated 
with other untrusted code on the stack. Maybe your code attempts to 
create the security manager does do with so privileges enabled, therwise 
everything that could potentially call you would also needed to be 
granted this permission.

-Alan.


From Alan.Bateman at oracle.com  Sun Jun 16 19:44:17 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Jun 2013 20:44:17 +0100
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51B9B157.10708@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
Message-ID: <51BE1591.8010901@oracle.com>

On 13/06/2013 12:47, Aleksey Shipilev wrote:
> Friendly reminder for the reviewers.
>
> On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
>> This is the follow-up on the issue Doug identified:
>>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
>>
>> I had reworked the patch, webrev is here:
>>    http://cr.openjdk.java.net/~shade/8016236/webrev.01/
> The current webrev is here:
>    http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>
I'm just catching up on this thread, webrev.02 looks very good to me. I 
can sponsor it.

One comment on ClassRepositoryHolder is that it's "yet another class" 
(we have a proliferation of holder classes since we started using this 
idiom). It makes me wonder if it might be better to move the constant to 
ClassRepository.

-Alan.




From Alan.Bateman at oracle.com  Sun Jun 16 19:58:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 16 Jun 2013 20:58:02 +0100
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51B63DCD.3060702@gmail.com>
References: <51B5F684.9010600@oracle.com> <51B63DCD.3060702@gmail.com>
Message-ID: <51BE18CA.70003@oracle.com>

On 10/06/2013 21:57, Peter Levart wrote:
> :
>
> I should note that ReflectionData is invalidated when the class is 
> redefined. I don't know if generic signature is one of those things 
> that can change with class redefinition, but invalidation is just one 
> purpose of ReflectionData and the other is caching (via 
> SoftReference), so generic signature can be added to it for that 
> purpose. If 'genericSignature' is cached on ReflectionData then it 
> would be consistent to also cache the derived 'genericInfo', what do 
> you think?
>
A redefine or retransform is allowed to change attributes so while 
signatures/modifier/hierarchy can't change then the Signature attribute 
might. So I think it's right in the current webrev (but good to think 
about such things).

-Alan.


From nicholas+openjdk at nicholaswilliams.net  Sun Jun 16 23:06:23 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sun, 16 Jun 2013 18:06:23 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: 
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
	
Message-ID: 


On Jun 16, 2013, at 9:29 AM, Nick Williams wrote:

> 
> On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:
> 
>> Nick Williams wrote:
>>> I'm going to stick by my original assessment that I'm not convinced
>>> there's a security issue. It's possible that getClassContext() filters
>>> out classes the caller can't access, but nothing in the documentation
>>> indicates that's the case, so I'm operating under the assumption that it
>>> doesn't.
>> 
>> SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument.
> 
> Can you define what "is not available to unprivileged callers" means a little better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just fine. I took a look at the Java code, and it's native, so there's no check there. (You can't instantiate a SecurityManager unless there's not currently a SecurityManager installed _OR_ the installed SecurityManager allows the creation (installation privilege isn't checked) of another SecurityManager. Is that what you're talking about?) I took a look at the native code, and I don't see anything there that would represent a privilege check that I recognized, but if I understood what you meant a little better I might see where I'm wrong.
> 
>> Given the security implications, the serialization issue and the need for weak references, it seems to me that adding this to Throwable would be way too expensive. 
> 
> The only expense I'm seeing here is the security implications, and I'm still not convinced that they exist. We have all agreed now that making this transient is okay, and adding the transient keyword to a field only takes 5 seconds. And I certainly don't believe that declaring the field as "WeakReference> elementClass" instead of "Class elementClass" takes more than 30 seconds longer, but maybe I'm missing something, so that's not expensive either.
> 
> Also, to be clear, I'm not suggesting adding it to Throwable specifically, I'm suggesting adding it to StackTraceElement (which would apply anywhere that a stack trace is filled in, including Throwable). A stack trace is filled in with one native code method, so updating that method will make this work in Throwable, Thread, and anywhere else that you can get a stack trace. I know this is a nitpicky distinction, but it could be important.
> 
>> 
>> Adding a new API to collect a stack trace seems like a far better approach.
>> 
>> Here's my off the cuff proposal:
>> 
>> public final class StackFrame {
>> public Executable method();
>> public String getFileName();
>> public int getLineNumber();
>> 
>> public static StackFrame[] capture(int skipFrames, int maxLength, boolean includeSourceInfo);
>> }
>> 
> 
> I'm not opposed to the StackFrame class as suggested, it just doesn't meet my needs. At all. I can already successfully get this information using the stack trace and getClassContext(), so I wouldn't be compelled to switch. I need to efficiently get the Class from a stack trace generated by a Throwable, which this does not solve. Right now I'm having to resort to getting that Class using inefficient methods.

What if we also added a getStackFrames() method to Throwable? That would meet my needs but it would also satisfy what I'm observing is a desire to have a new API for this (StackFrame) instead of adding it to StackTraceElement. I'm very open to how it's implemented, as long as it satisfies my use case. :-)

The stack trace of a Throwable can be "filled in" on demand when getStackTrace() is called the first time, so that the overhead isn't incurred when creating and throwing the exception. Presumably, we would need to do something similar with getStackFrames(), especially since calling it would be less common.

Thoughts on this?

From joe.darcy at oracle.com  Sun Jun 16 23:34:33 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 16 Jun 2013 16:34:33 -0700
Subject: Cleanup of doclint warnings in java.lang.{annotation, reflect}
Message-ID: <51BE4B89.3080102@oracle.com>

Hello,

Please review the diff below of changes to get java.lang.annotation and 
java.lang.reflect clean on doclint warnings.

I soon plan to send out another patch to cleanup java.lang; I'll file 
one or more bugs to cover this work depending on how reviews come in.

Thanks,

-Joe

diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Annotation.java
--- a/src/share/classes/java/lang/annotation/Annotation.java    Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/annotation/Annotation.java    Sun Jun 
16 16:34:09 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -126,6 +126,7 @@

      /**
       * Returns the annotation type of this annotation.
+     * @return the annotation type of this annotation
       */
      Class annotationType();
  }
diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Repeatable.java
--- a/src/share/classes/java/lang/annotation/Repeatable.java    Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/annotation/Repeatable.java    Sun Jun 
16 16:34:09 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -43,6 +43,7 @@
      /**
       * Indicates the containing annotation type for the
       * repeatable annotation type.
+     * @return the containing annotation type
       */
      Class value();
  }
diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Retention.java
--- a/src/share/classes/java/lang/annotation/Retention.java    Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/annotation/Retention.java    Sun Jun 
16 16:34:09 2013 -0700
@@ -44,5 +44,9 @@
  @Retention(RetentionPolicy.RUNTIME)
  @Target(ElementType.ANNOTATION_TYPE)
  public @interface Retention {
+    /**
+     * Returns the retention policy.
+     * @return the retention policy
+     */
      RetentionPolicy value();
  }
diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Target.java
--- a/src/share/classes/java/lang/annotation/Target.java    Fri Jun 14 
15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/annotation/Target.java    Sun Jun 16 
16:34:09 2013 -0700
@@ -67,5 +67,11 @@
  @Retention(RetentionPolicy.RUNTIME)
  @Target(ElementType.ANNOTATION_TYPE)
  public @interface Target {
+    /**
+     * Returns an array of the kinds of elements an annotation type
+     * can be applied to.
+     * @return an array of the kinds of elements an annotation type
+     * can be applied to
+     */
      ElementType[] value();
  }
diff -r 45a3584bfacf 
src/share/classes/java/lang/reflect/AnnotatedElement.java
--- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Sun Jun 
16 16:34:09 2013 -0700
@@ -130,6 +130,7 @@
       * Returns this element's annotation for the specified type if
       * such an annotation is present, else null.
       *
+     * @param  the type of the annotation to query for and return if 
present
       * @param annotationClass the Class object corresponding to the
       *        annotation type
       * @return this element's annotation for the specified annotation 
type if
@@ -154,6 +155,7 @@
       * The caller of this method is free to modify the returned array; 
it will
       * have no effect on the arrays returned to other callers.
       *
+     * @param  the type of the annotation to query for and return if 
present
       * @param annotationClass the Class object corresponding to the
       *        annotation type
       * @return all this element's annotations for the specified 
annotation type if
@@ -184,6 +186,7 @@
       * This method ignores inherited annotations. (Returns null if no
       * annotations are directly present on this element.)
       *
+     * @param  the type of the annotation to query for and return if 
present
       * @param annotationClass the Class object corresponding to the
       *        annotation type
       * @return this element's annotation for the specified annotation 
type if
@@ -209,6 +212,8 @@
       * The caller of this method is free to modify the returned array; 
it will
       * have no effect on the arrays returned to other callers.
       *
+     * @param  the type of the annotation to query for and return
+     * if directly present
       * @param annotationClass the Class object corresponding to the
       *        annotation type
       * @return all this element's annotations for the specified 
annotation type if
diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Executable.java
--- a/src/share/classes/java/lang/reflect/Executable.java    Fri Jun 14 
15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/reflect/Executable.java    Sun Jun 16 
16:34:09 2013 -0700
@@ -384,6 +384,8 @@
      /**
       * Returns a string describing this {@code Executable}, including
       * any type parameters.
+     * @return a string describing this {@code Executable}, including
+     * any type parameters
       */
      public abstract String toGenericString();

@@ -496,6 +498,8 @@
       * If this Executable represents a method, the AnnotatedType object
       * represents the use of a type to specify the return type of the 
method.
       *
+     * @return an object representing the return type of this method
+     * or constructor
       * @since 1.8
       */
      public abstract AnnotatedType getAnnotatedReturnType();
@@ -531,6 +535,9 @@
       *
       * Returns null if this Executable represents a static method.
       *
+     * @return an object representing the receiver type of the
+     * method or constructor represented by this Executable
+     *
       * @since 1.8
       */
      public AnnotatedType getAnnotatedReceiverType() {
@@ -553,6 +560,9 @@
       * Returns an array of length 0 if the method/constructor declares no
       * parameters.
       *
+     * @return an array of objects representing the types of the
+     * formal parameters of this method or constructor
+     *
       * @since 1.8
       */
      public AnnotatedType[] getAnnotatedParameterTypes() {
@@ -575,6 +585,9 @@
       * Returns an array of length 0 if the method/constructor declares no
       * exceptions.
       *
+     * @return an array of objects representing the declared
+     * exceptions of this method or constructor
+     *
       * @since 1.8
       */
      public AnnotatedType[] getAnnotatedExceptionTypes() {
diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Field.java
--- a/src/share/classes/java/lang/reflect/Field.java    Fri Jun 14 
15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/reflect/Field.java    Sun Jun 16 
16:34:09 2013 -0700
@@ -1151,7 +1151,9 @@
      /**
       * Returns an AnnotatedType object that represents the use of a 
type to specify
       * the declared type of the field represented by this Field.
-     *
+     * @return an object representing the declared type of the field
+     * represented by this Field
+     *
       * @since 1.8
       */
      public AnnotatedType getAnnotatedType() {
diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Parameter.java
--- a/src/share/classes/java/lang/reflect/Parameter.java    Fri Jun 14 
15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/reflect/Parameter.java    Sun Jun 16 
16:34:09 2013 -0700
@@ -152,6 +152,8 @@
       * defined in a class file, then that name will be returned by
       * this method.  Otherwise, this method will synthesize a name of
       * the form argN, where N is the index of the parameter.
+     *
+     * @return the name of the parameter
       */
      public String getName() {
          // Note: empty strings as paramete names are now outlawed.
diff -r 45a3584bfacf src/share/classes/java/lang/reflect/TypeVariable.java
--- a/src/share/classes/java/lang/reflect/TypeVariable.java    Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/reflect/TypeVariable.java    Sun Jun 
16 16:34:09 2013 -0700
@@ -95,6 +95,7 @@
       *
       * Returns an array of length 0 if the type parameter declares no 
bounds.
       *
+     * @return an array of objects representing the upper bounds of the 
type variable
       * @since 1.8
       */
       AnnotatedType[] getAnnotatedBounds();



From joe.darcy at oracle.com  Mon Jun 17 03:48:02 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 16 Jun 2013 20:48:02 -0700
Subject: Cleanup of some doclint warnings in java.lang
Message-ID: <51BE86F2.8060104@oracle.com>

Hello,

Please review the patch below which resolves a subset of the doclint 
warnings in java.lang.

Thanks,

-Joe

diff -r 45a3584bfacf src/share/classes/java/lang/Boolean.java
--- a/src/share/classes/java/lang/Boolean.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/Boolean.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -205,9 +205,9 @@
       * Returns a hash code for a {@code boolean} value; compatible with
       * {@code Boolean.hashCode()}.
       *
+     * @param value the value to hash
+     * @return a hash code value for a {@code boolean} value.
       * @since 1.8
-     *
-     * @return a hash code value for a {@code boolean} value.
       */
      public static int hashCode(boolean value) {
          return value ? 1231 : 1237;
diff -r 45a3584bfacf src/share/classes/java/lang/Byte.java
--- a/src/share/classes/java/lang/Byte.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Byte.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -398,9 +398,9 @@
       * Returns a hash code for a {@code byte} value; compatible with
       * {@code Byte.hashCode()}.
       *
+     * @param value the value to hash
+     * @return a hash code value for a {@code byte} value.
       * @since 1.8
-     *
-     * @return a hash code value for a {@code byte} value.
       */
      public static int hashCode(byte value) {
          return (int)value;
diff -r 45a3584bfacf src/share/classes/java/lang/Class.java
--- a/src/share/classes/java/lang/Class.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Class.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -3141,6 +3141,8 @@
       * could not be checked at runtime (because generic types are 
implemented
       * by erasure).
       *
+     * @param  the type to cast this class object to
+     * @param clazz the class of the type to cast this class object to
       * @return this {@code Class} object, cast to represent a subclass of
       *    the specified class object.
       * @throws ClassCastException if this {@code Class} object does not
@@ -3296,6 +3298,7 @@
       * If this Class represents either the Object class, an interface 
type, an
       * array type, a primitive type, or void, the return value is null.
       *
+     * @return an object representing the superclass
       * @since 1.8
       */
      public AnnotatedType getAnnotatedSuperclass() {
@@ -3327,6 +3330,7 @@
       * If this Class represents either the Object class, an array type, a
       * primitive type, or void, the return value is an array of length 0.
       *
+     * @return an array representing the superinterfaces
       * @since 1.8
       */
      public AnnotatedType[] getAnnotatedInterfaces() {
diff -r 45a3584bfacf src/share/classes/java/lang/Double.java
--- a/src/share/classes/java/lang/Double.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/Double.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -453,7 +453,6 @@
       * a {@code NumberFormatException} be thrown, the regular
       * expression below can be used to screen the input string:
       *
-     * 
       * 
           *  final String Digits     = "(\\p{Digit}+)";
       *  final String HexDigits  = "(\\p{XDigit}+)";
@@ -500,7 +499,6 @@
       *      // Perform suitable alternative action
       *  }
       * 
    
-     * 
       *
       * @param      s   the string to be parsed.
       * @return     a {@code Double} object holding the value
@@ -756,9 +754,9 @@
       * Returns a hash code for a {@code double} value; compatible with
       * {@code Double.hashCode()}.
       *
+     * @param value the value to hash
+     * @return a hash code value for a {@code double} value.
       * @since 1.8
-     *
-     * @return a hash code value for a {@code double} value.
       */
      public static int hashCode(double value) {
          long bits = doubleToLongBits(value);
diff -r 45a3584bfacf src/share/classes/java/lang/Float.java
--- a/src/share/classes/java/lang/Float.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Float.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -664,9 +664,9 @@
       * Returns a hash code for a {@code float} value; compatible with
       * {@code Float.hashCode()}.
       *
+     * @param value the value to hash
+     * @return a hash code value for a {@code float} value.
       * @since 1.8
-     *
-     * @return a hash code value for a {@code float} value.
       */
      public static int hashCode(float value) {
          return floatToIntBits(value);
diff -r 45a3584bfacf src/share/classes/java/lang/Integer.java
--- a/src/share/classes/java/lang/Integer.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/Integer.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -947,6 +947,7 @@
       * Returns a hash code for a {@code int} value; compatible with
       * {@code Integer.hashCode()}.
       *
+     * @param value the value to hash
       * @since 1.8
       *
       * @return a hash code value for a {@code int} value.
@@ -1332,6 +1333,7 @@
       * one-bits in its two's complement binary representation, that 
is, if it
       * is equal to zero.
       *
+     * @param i the value whose highest one bit is to be computed
       * @return an {@code int} value with a single one-bit, in the position
       *     of the highest-order one-bit in the specified value, or zero if
       *     the specified value is itself equal to zero.
@@ -1354,6 +1356,7 @@
       * one-bits in its two's complement binary representation, that 
is, if it
       * is equal to zero.
       *
+     * @param i the value whose lowest one bit is to be computed
       * @return an {@code int} value with a single one-bit, in the position
       *     of the lowest-order one-bit in the specified value, or zero if
       *     the specified value is itself equal to zero.
@@ -1378,6 +1381,7 @@
       * 
  • ceil(log2(x)) = {@code 32 - 
numberOfLeadingZeros(x - 1)}
       * 
       *
+     * @param i the value whose number of leading zeros is to be computed
       * @return the number of zero bits preceding the highest-order
       *     ("leftmost") one-bit in the two's complement binary 
representation
       *     of the specified {@code int} value, or 32 if the value
@@ -1404,6 +1408,7 @@
       * one-bits in its two's complement representation, in other words 
if it is
       * equal to zero.
       *
+     * @param i the value whose number of trailing zeros is to be computed
       * @return the number of zero bits following the lowest-order 
("rightmost")
       *     one-bit in the two's complement binary representation of the
       *     specified {@code int} value, or 32 if the value is equal
@@ -1427,6 +1432,7 @@
       * representation of the specified {@code int} value.  This 
function is
       * sometimes referred to as the population count.
       *
+     * @param i the value whose bits are to be counted
       * @return the number of one-bits in the two's complement binary
       *     representation of the specified {@code int} value.
       * @since 1.5
@@ -1454,6 +1460,8 @@
       * ignored, even if the distance is negative: {@code rotateLeft(val,
       * distance) == rotateLeft(val, distance & 0x1F)}.
       *
+     * @param i the value whose bits are to be rotated left
+     * @param distance the number of bit positions to rotate left
       * @return the value obtained by rotating the two's complement binary
       *     representation of the specified {@code int} value left by the
       *     specified number of bits.
@@ -1476,6 +1484,8 @@
       * ignored, even if the distance is negative: {@code rotateRight(val,
       * distance) == rotateRight(val, distance & 0x1F)}.
       *
+     * @param i the value whose bits are to be rotated right
+     * @param distance the number of bit positions to rotate right
       * @return the value obtained by rotating the two's complement binary
       *     representation of the specified {@code int} value right by the
       *     specified number of bits.
@@ -1490,6 +1500,7 @@
       * two's complement binary representation of the specified {@code int}
       * value.
       *
+     * @param i the value to be reversed
       * @return the value obtained by reversing order of the bits in the
       *     specified {@code int} value.
       * @since 1.5
@@ -1509,6 +1520,7 @@
       * return value is -1 if the specified value is negative; 0 if the
       * specified value is zero; and 1 if the specified value is positive.)
       *
+     * @param i the value whose signum is to be computed
       * @return the signum function of the specified {@code int} value.
       * @since 1.5
       */
@@ -1521,6 +1533,7 @@
       * Returns the value obtained by reversing the order of the bytes 
in the
       * two's complement representation of the specified {@code int} value.
       *
+     * @param i the value whose bytes are to be reversed
       * @return the value obtained by reversing the bytes in the specified
       *     {@code int} value.
       * @since 1.5
diff -r 45a3584bfacf src/share/classes/java/lang/Long.java
--- a/src/share/classes/java/lang/Long.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Long.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -1053,9 +1053,9 @@
       * Returns a hash code for a {@code long} value; compatible with
       * {@code Long.hashCode()}.
       *
+     * @param value the value to hash
+     * @return a hash code value for a {@code long} value.
       * @since 1.8
-     *
-     * @return a hash code value for a {@code long} value.
       */
      public static int hashCode(long value) {
          return (int)(value ^ (value >>> 32));
@@ -1357,6 +1357,7 @@
       * one-bits in its two's complement binary representation, that 
is, if it
       * is equal to zero.
       *
+     * @param i the value whose highest one bit is to be computed
       * @return a {@code long} value with a single one-bit, in the position
       *     of the highest-order one-bit in the specified value, or zero if
       *     the specified value is itself equal to zero.
@@ -1380,6 +1381,7 @@
       * one-bits in its two's complement binary representation, that 
is, if it
       * is equal to zero.
       *
+     * @param i the value whose lowest one bit is to be computed
       * @return a {@code long} value with a single one-bit, in the position
       *     of the lowest-order one-bit in the specified value, or zero if
       *     the specified value is itself equal to zero.
@@ -1404,6 +1406,7 @@
       * 
  • ceil(log2(x)) = {@code 64 - 
numberOfLeadingZeros(x - 1)}
       * 
       *
+     * @param i the value whose number of leading zeros is to be computed
       * @return the number of zero bits preceding the highest-order
       *     ("leftmost") one-bit in the two's complement binary 
representation
       *     of the specified {@code long} value, or 64 if the value
@@ -1432,6 +1435,7 @@
       * one-bits in its two's complement representation, in other words 
if it is
       * equal to zero.
       *
+     * @param i the value whose number of trailing zeros is to be computed
       * @return the number of zero bits following the lowest-order 
("rightmost")
       *     one-bit in the two's complement binary representation of the
       *     specified {@code long} value, or 64 if the value is equal
@@ -1456,6 +1460,7 @@
       * representation of the specified {@code long} value.  This 
function is
       * sometimes referred to as the population count.
       *
+     * @param i the value whose bits are to be counted
       * @return the number of one-bits in the two's complement binary
       *     representation of the specified {@code long} value.
       * @since 1.5
@@ -1484,6 +1489,8 @@
       * ignored, even if the distance is negative: {@code rotateLeft(val,
       * distance) == rotateLeft(val, distance & 0x3F)}.
       *
+     * @param i the value whose bits are to be rotated left
+     * @param distance the number of bit positions to rotate left
       * @return the value obtained by rotating the two's complement binary
       *     representation of the specified {@code long} value left by the
       *     specified number of bits.
@@ -1506,6 +1513,8 @@
       * ignored, even if the distance is negative: {@code rotateRight(val,
       * distance) == rotateRight(val, distance & 0x3F)}.
       *
+     * @param i the value whose bits are to be rotated right
+     * @param distance the number of bit positions to rotate right
       * @return the value obtained by rotating the two's complement binary
       *     representation of the specified {@code long} value right by the
       *     specified number of bits.
@@ -1520,6 +1529,7 @@
       * two's complement binary representation of the specified {@code 
long}
       * value.
       *
+     * @param i the value to be reversed
       * @return the value obtained by reversing order of the bits in the
       *     specified {@code long} value.
       * @since 1.5
@@ -1540,6 +1550,7 @@
       * return value is -1 if the specified value is negative; 0 if the
       * specified value is zero; and 1 if the specified value is positive.)
       *
+     * @param i the value whose signum is to be computed
       * @return the signum function of the specified {@code long} value.
       * @since 1.5
       */
@@ -1552,6 +1563,7 @@
       * Returns the value obtained by reversing the order of the bytes 
in the
       * two's complement representation of the specified {@code long} 
value.
       *
+     * @param i the value whose bytes are to be reversed
       * @return the value obtained by reversing the bytes in the specified
       *     {@code long} value.
       * @since 1.5
diff -r 45a3584bfacf src/share/classes/java/lang/Math.java
--- a/src/share/classes/java/lang/Math.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Math.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
diff -r 45a3584bfacf src/share/classes/java/lang/Package.java
--- a/src/share/classes/java/lang/Package.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/Package.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -77,18 +77,18 @@
   * by the following formal grammar:
   * 
    
   * 
    
- * 
    SpecificationVersion:
- * 
    Digits RefinedVersionopt
+ * 
    SpecificationVersion:
+ * 
    Digits RefinedVersionopt

- * 
    RefinedVersion:
+ * 
    RefinedVersion:
   * 
    {@code .} Digits
   * 
    {@code .} Digits RefinedVersion
   *
- * 
    Digits:
- * 
    Digit
- * 
    Digits
+ * 
    Digits:
+ * 
    Digit
+ * 
    Digits
   *
- * 
    Digit:
+ * 
    Digit:
   * 
    any character for which {@link Character#isDigit} returns 
{@code true},
   * e.g. 0, 1, 2, ...
   * 
    
diff -r 45a3584bfacf src/share/classes/java/lang/Runtime.java
--- a/src/share/classes/java/lang/Runtime.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/Runtime.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -117,11 +117,11 @@
       *
       *   
      
       *
-     *   
       
    •  The program exits normally, when the last 
non-daemon
+     *   
    •  The program exits normally, when the last non-daemon
       *   thread exits or when the {@link #exit exit} 
(equivalently,
-     *   {@link System#exit(int) System.exit}) method is 
invoked, or
+     *   {{@link System#exit(int) System.exit}) method is 
invoked, or
       *
-     *   
       
    •  The virtual machine is terminated in response to a
+     *   
    •  The virtual machine is terminated in response to a
       *   user interrupt, such as typing ^C, or a system-wide 
event,
       *   such as user logoff or system shutdown.
       *
diff -r 45a3584bfacf src/share/classes/java/lang/Short.java
--- a/src/share/classes/java/lang/Short.java    Fri Jun 14 15:14:56 2013 
+0400
+++ b/src/share/classes/java/lang/Short.java    Sun Jun 16 20:46:52 2013 
-0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -405,6 +405,7 @@
       *
       * @since 1.8
       *
+     * @param value the value to hash
       * @return a hash code value for a {@code short} value.
       */
      public static int hashCode(short value) {
@@ -482,6 +483,7 @@
       * Returns the value obtained by reversing the order of the bytes 
in the
       * two's complement representation of the specified {@code short} 
value.
       *
+     * @param i the value whose bytes are to be reversed
       * @return the value obtained by reversing (or, equivalently, 
swapping)
       *     the bytes in the specified {@code short} value.
       * @since 1.5
diff -r 45a3584bfacf src/share/classes/java/lang/StrictMath.java
--- a/src/share/classes/java/lang/StrictMath.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/StrictMath.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -1419,6 +1419,7 @@
       * {@link Float#MIN_EXPONENT} -1.
       * 
    
       * @param f a {@code float} value
+     * @return the unbiased exponent of the argument
       * @since 1.6
       */
      public static int getExponent(float f) {
@@ -1436,6 +1437,7 @@
       * {@link Double#MIN_EXPONENT} -1.
       * 
       * @param d a {@code double} value
+     * @return the unbiased exponent of the argument
       * @since 1.6
       */
      public static int getExponent(double d) {
diff -r 45a3584bfacf src/share/classes/java/lang/SuppressWarnings.java
--- a/src/share/classes/java/lang/SuppressWarnings.java    Fri Jun 14 
15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/SuppressWarnings.java    Sun Jun 16 
20:46:52 2013 -0700
@@ -66,6 +66,7 @@
       * additional warning names they support in conjunction with this
       * annotation type. They are encouraged to cooperate to ensure
       * that the same names work across multiple compilers.
+     * @return the set of warnings to be suppressed
       */
      String[] value();
  }
diff -r 45a3584bfacf src/share/classes/java/lang/System.java
--- a/src/share/classes/java/lang/System.java    Fri Jun 14 15:14:56 
2013 +0400
+++ b/src/share/classes/java/lang/System.java    Sun Jun 16 20:46:52 
2013 -0700
@@ -634,6 +634,8 @@
       *
       * 
    On UNIX systems, it returns {@code "\n"}; on Microsoft
       * Windows systems it returns {@code "\r\n"}.
+     *
+     * @return the system-dependent line separator string
       * @since 1.7
       */
      public static String lineSeparator() {
diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Annotation.java
--- a/src/share/classes/java/lang/annotation/Annotation.java    Fri Jun 
14 15:14:56 2013 +0400
+++ b/src/share/classes/java/lang/annotation/Annotation.java    Sun Jun 
16 20:46:52 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -126,6 +126,7 @@

      /**
       * Returns the annotation type of this annotation.
+     * @return the annotation type of this annotation
       */
      Class annotationType();



From peter.levart at gmail.com  Mon Jun 17 06:06:04 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 17 Jun 2013 08:06:04 +0200
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BE1591.8010901@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com>
Message-ID: <51BEA74C.4090002@gmail.com>

On 06/16/2013 09:44 PM, Alan Bateman wrote:
> On 13/06/2013 12:47, Aleksey Shipilev wrote:
>> Friendly reminder for the reviewers.
>>
>> On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
>>> This is the follow-up on the issue Doug identified:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
>>>
>>> I had reworked the patch, webrev is here:
>>>    http://cr.openjdk.java.net/~shade/8016236/webrev.01/
>> The current webrev is here:
>>    http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>>
> I'm just catching up on this thread, webrev.02 looks very good to me. 
> I can sponsor it.
>
> One comment on ClassRepositoryHolder is that it's "yet another class" 
> (we have a proliferation of holder classes since we started using this 
> idiom). It makes me wonder if it might be better to move the constant 
> to ClassRepository.

That's a good idea. Since it's in a package different from java.lang, 
the field would have to be public. So perhaps a chain of no-arg 
constructors could be used to construct such instance which would be 
unusable for any purpose other than identity comparison.

Peter

>
> -Alan.
>
>



From jeroen at sumatra.nl  Mon Jun 17 06:06:29 2013
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Mon, 17 Jun 2013 06:06:29 +0000
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: 
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
	
	
Message-ID: <3c60eb649bae43c59773380ee19cff75@mane.sumatrasoftware.com>

Nick Williams wrote:
> What if we also added a getStackFrames() method to Throwable? That would
> meet my needs but it would also satisfy what I'm observing is a desire
> to have a new API for this (StackFrame) instead of adding it to
> StackTraceElement. I'm very open to how it's implemented, as long as it
> satisfies my use case. :-)
> 
> The stack trace of a Throwable can be "filled in" on demand when
> getStackTrace() is called the first time, so that the overhead isn't
> incurred when creating and throwing the exception. Presumably, we would
> need to do something similar with getStackFrames(), especially since
> calling it would be less common.
> 
> Thoughts on this?

Yes that is reasonable, but I'd add a static method to StackFrame instead. Something like StackFrame[] capture(Throwable).

Regards,
Jeroen



From peter.levart at gmail.com  Mon Jun 17 06:12:11 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 17 Jun 2013 08:12:11 +0200
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <3c60eb649bae43c59773380ee19cff75@mane.sumatrasoftware.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
	
	
	<3c60eb649bae43c59773380ee19cff75@mane.sumatrasoftware.com>
Message-ID: <51BEA8BB.60406@gmail.com>

On 06/17/2013 08:06 AM, Jeroen Frijters wrote:
> Nick Williams wrote:
>> What if we also added a getStackFrames() method to Throwable? That would
>> meet my needs but it would also satisfy what I'm observing is a desire
>> to have a new API for this (StackFrame) instead of adding it to
>> StackTraceElement. I'm very open to how it's implemented, as long as it
>> satisfies my use case. :-)
>>
>> The stack trace of a Throwable can be "filled in" on demand when
>> getStackTrace() is called the first time, so that the overhead isn't
>> incurred when creating and throwing the exception. Presumably, we would
>> need to do something similar with getStackFrames(), especially since
>> calling it would be less common.
>>
>> Thoughts on this?
> Yes that is reasonable, but I'd add a static method to StackFrame instead. Something like StackFrame[] capture(Throwable).

New API could be entirely unrelated to Throwable, if there was support 
for it in native code. Since there would have to be changes to the 
native code anyway to support this, why not create a separate API?

Regards, Peter

>
> Regards,
> Jeroen
>



From martinrb at google.com  Mon Jun 17 06:14:55 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 16 Jun 2013 23:14:55 -0700
Subject: Inefficient code of String.indexOf(String)
In-Reply-To: 
References: 
Message-ID: 

You are not the first person to have this idea.
It is unlikely that you will succeed in changing the algorithm, because the
jit-optimized brute-force algorithm is "almost always" faster.
But go ahead and prove me wrong!


On Sun, Jun 16, 2013 at 3:53 AM, Anubhav Chaturvedi <
mailforanubhav at gmail.com> wrote:

> Hello,
>
> I have recently started to explore the source code and am new to the open
> source community. I observed that in String.class within java.lang , the
> indexOf method, line 1715, uses the bruteforce approach when it comes to
> string matching. This method is used by the contains(CharSequence) method.
> There are a number of algorithms that can perform the task more
> efficiently.
>
> I would like to bring the required changes and needed your advice on this.
>
> --
> *Regards,*
> *Anubhav Chaturvedi*
>
> *Birla Institute of Technology & Science, Pilani*
> KK Birla Goa Campus
> +91-9637399150
>


From lana.steuck at oracle.com  Mon Jun 17 06:30:44 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:44 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130617063049.42CFC48258@hg.openjdk.java.net>

Changeset: e857ab684db0
Author:    cl
Date:      2013-06-06 20:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e857ab684db0

Added tag jdk8-b93 for changeset ddbf41575a2b

! .hgtags

Changeset: d92b756bc739
Author:    lana
Date:      2013-06-10 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d92b756bc739

Merge

- src/jdk/nashorn/internal/objects/DateParser.java

Changeset: cbc9926f5b40
Author:    katleman
Date:      2013-06-13 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cbc9926f5b40

Added tag jdk8-b94 for changeset d92b756bc739

! .hgtags

Changeset: 558d31c168ed
Author:    lana
Date:      2013-06-16 22:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/558d31c168ed

Merge




From lana.steuck at oracle.com  Mon Jun 17 06:30:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:39 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20130617063053.2A7F848259@hg.openjdk.java.net>

Changeset: 254c53fd97ab
Author:    katleman
Date:      2013-06-06 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/254c53fd97ab

Added tag jdk8-b93 for changeset 7386eca865e1

! .hgtags

Changeset: 1468c94135f9
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1468c94135f9

Added tag jdk8-b94 for changeset 254c53fd97ab

! .hgtags

Changeset: c4191a46e3eb
Author:    lana
Date:      2013-06-16 22:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c4191a46e3eb

Merge




From lana.steuck at oracle.com  Mon Jun 17 06:30:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:39 +0000
Subject: hg: jdk8/tl: 13 new changesets
Message-ID: <20130617063040.CD5A348256@hg.openjdk.java.net>

Changeset: 33b6df33a2b7
Author:    erikj
Date:      2013-05-29 13:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/33b6df33a2b7

8013920: Configure sets JOBS to 0 if memory is too low.
Reviewed-by: tbell

! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh

Changeset: 03e60e87d92a
Author:    erikj
Date:      2013-05-29 14:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/03e60e87d92a

8013489: New build system does not run codesign on SA-related launchers on OS X
Reviewed-by: sla, tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/MakeBase.gmk
! common/makefiles/NativeCompilation.gmk

Changeset: c31e9dc1fe3d
Author:    erikj
Date:      2013-05-31 14:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c31e9dc1fe3d

8014003: New build does not handle symlinks in workspace path
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/basics_windows.m4
! common/autoconf/generated-configure.sh

Changeset: 44259699e0b5
Author:    erikj
Date:      2013-06-04 10:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/44259699e0b5

8015784: Add configure parameter --with-update-version
Reviewed-by: tbell, katleman, erikj
Contributed-by: tristan.yan at oracle.com

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: db3144e1f89b
Author:    mduigou
Date:      2013-06-04 10:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/db3144e1f89b

8015510: (s) Improve JTReg location detection and provide location to test/Makefile
Reviewed-by: erikj

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4
! common/makefiles/Main.gmk

Changeset: 9b8e8098172c
Author:    katleman
Date:      2013-06-04 11:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/9b8e8098172c

Merge


Changeset: f55734874c4f
Author:    katleman
Date:      2013-06-04 15:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f55734874c4f

Merge

! common/autoconf/generated-configure.sh

Changeset: 27c51c6e31c1
Author:    katleman
Date:      2013-06-05 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/27c51c6e31c1

6983966: remove lzma and upx from repository JDK8
Reviewed-by: tbell, paulk, ngthomas

! common/autoconf/generated-configure.sh
! common/makefiles/Jprt.gmk
! make/deploy-rules.gmk

Changeset: 8dfb6ee04114
Author:    katleman
Date:      2013-06-06 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8dfb6ee04114

Added tag jdk8-b93 for changeset 27c51c6e31c1

! .hgtags

Changeset: 198d25db45da
Author:    erikj
Date:      2013-06-11 13:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/198d25db45da

8008707: build-infra: Closed (deploy) can't be built using environment from SDK SetEnv.cmd
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain_windows.m4

Changeset: 3cbcc2b6ba41
Author:    erikj
Date:      2013-06-11 13:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/3cbcc2b6ba41

8010785: JDK 8 build on Linux fails with new build mechanism
Reviewed-by: dholmes, tbell

! common/autoconf/generated-configure.sh
! common/autoconf/jdk-options.m4

Changeset: 50d2bde060f2
Author:    erikj
Date:      2013-06-12 10:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/50d2bde060f2

Merge


Changeset: 6337f652e71f
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/6337f652e71f

Added tag jdk8-b94 for changeset 50d2bde060f2

! .hgtags



From lana.steuck at oracle.com  Mon Jun 17 06:30:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:39 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20130617063042.ACA5348257@hg.openjdk.java.net>

Changeset: 22f5d7f261d9
Author:    katleman
Date:      2013-06-06 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/22f5d7f261d9

Added tag jdk8-b93 for changeset 8dc9d7ccbb2d

! .hgtags

Changeset: 2cf36f43df36
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/2cf36f43df36

Added tag jdk8-b94 for changeset 22f5d7f261d9

! .hgtags

Changeset: 0fac0a9d9545
Author:    lana
Date:      2013-06-16 22:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/0fac0a9d9545

Merge




From lana.steuck at oracle.com  Mon Jun 17 06:30:39 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:39 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20130617063057.20CF54825A@hg.openjdk.java.net>

Changeset: 40da96cab40e
Author:    katleman
Date:      2013-06-06 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/40da96cab40e

Added tag jdk8-b93 for changeset d583a491d63c

! .hgtags

Changeset: c84658e1740d
Author:    lana
Date:      2013-06-10 16:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c84658e1740d

Merge


Changeset: b8c5f4b6f0ff
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b8c5f4b6f0ff

Added tag jdk8-b94 for changeset c84658e1740d

! .hgtags

Changeset: 0142ef23f1b4
Author:    lana
Date:      2013-06-16 22:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0142ef23f1b4

Merge




From lana.steuck at oracle.com  Mon Jun 17 06:30:47 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:30:47 +0000
Subject: hg: jdk8/tl/langtools: 4 new changesets
Message-ID: <20130617063102.5F6454825B@hg.openjdk.java.net>

Changeset: 888386fddc09
Author:    katleman
Date:      2013-06-06 09:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/888386fddc09

Added tag jdk8-b93 for changeset 2c5a568ee36e

! .hgtags

Changeset: 48c6e6ab7c81
Author:    lana
Date:      2013-06-10 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/48c6e6ab7c81

Merge


Changeset: 4cb113623127
Author:    katleman
Date:      2013-06-13 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cb113623127

Added tag jdk8-b94 for changeset 48c6e6ab7c81

! .hgtags

Changeset: 1eb09dba594a
Author:    lana
Date:      2013-06-16 22:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1eb09dba594a

Merge




From nicholas+openjdk at nicholaswilliams.net  Mon Jun 17 06:32:40 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 17 Jun 2013 01:32:40 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <51BEA8BB.60406@gmail.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCCCC9.2080208@oracle.com>
	
	<51BCE519.3050009@gmail.com>
	
	<19c1619f36f24a80886e19898375f313@mane.sumatrasoftware.com>
	
	
	<3c60eb649bae43c59773380ee19cff75@mane.sumatrasoftware.com>
	<51BEA8BB.60406@gmail.com>
Message-ID: <9AECEC51-3688-48A8-8DEC-27F3DCB8EE59@nicholaswilliams.net>


On Jun 17, 2013, at 1:12 AM, Peter Levart wrote:

> On 06/17/2013 08:06 AM, Jeroen Frijters wrote:
>> Nick Williams wrote:
>>> What if we also added a getStackFrames() method to Throwable? That would
>>> meet my needs but it would also satisfy what I'm observing is a desire
>>> to have a new API for this (StackFrame) instead of adding it to
>>> StackTraceElement. I'm very open to how it's implemented, as long as it
>>> satisfies my use case. :-)
>>> 
>>> The stack trace of a Throwable can be "filled in" on demand when
>>> getStackTrace() is called the first time, so that the overhead isn't
>>> incurred when creating and throwing the exception. Presumably, we would
>>> need to do something similar with getStackFrames(), especially since
>>> calling it would be less common.
>>> 
>>> Thoughts on this?
>> Yes that is reasonable, but I'd add a static method to StackFrame instead. Something like StackFrame[] capture(Throwable).
> 
> New API could be entirely unrelated to Throwable, if there was support for it in native code. Since there would have to be changes to the native code anyway to support this, why not create a separate API?

I'm not sure who's misunderstanding who. :-)

If some third party code that I have no control over throws an exception and I catch that exception, or some other code catches the exception and passes it to my code (because my code is a logging framework), I need to get the StackFrame[] for _when the exception was thrown_. Not the StackFrame[] related to my current method execution. How can that possibly be entirely unrelated to throwable?

The way I understand Jereon's suggestion, I'm thinking StackFrame would look like this:

public final class StackFrame {
 public Executable method();
 public String getFileName();
 public int getLineNumber();
 /** Shortcut for getModifiers() and Modifiers.NATIVE */
 public int isNativeMethod();
 /** Format exactly like StackTraceElement#toString() */
 public String toString();

 /** Gets current executing stack with number of frames skipped and max length */
 public static StackFrame[] capture(int skipFrames, int maxLength, boolean includeSourceInfo);
 /** Gets current executing stack with no frames skipped and no max length */
 public static StackFrame[] capture();
 /** Gets stack from when Throwable was created. */
 public static StackFrame[] capture(Throwable t);
}

But perhaps I am missing something.

Nick

From lana.steuck at oracle.com  Mon Jun 17 06:31:07 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:31:07 +0000
Subject: hg: jdk8/tl/hotspot: 65 new changesets
Message-ID: <20130617063317.D17E64825C@hg.openjdk.java.net>

Changeset: 61dcf187a198
Author:    katleman
Date:      2013-06-06 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61dcf187a198

Added tag jdk8-b93 for changeset 573d86d412cd

! .hgtags

Changeset: 194b27b865bc
Author:    amurillo
Date:      2013-05-24 09:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/194b27b865bc

8015305: new hotspot build - hs25-b35
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ccdecfece956
Author:    bharadwaj
Date:      2013-05-21 16:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccdecfece956

8014059: JSR292: Failed to reject invalid class cplmhl00201m28n
Summary: Restrict reference of interface methods by invokestatic and invokespecial to classfile version 52 or later.
Reviewed-by: kvn, hseigel

! src/share/vm/classfile/classFileParser.cpp

Changeset: f54c85acc043
Author:    mikael
Date:      2013-05-21 09:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f54c85acc043

8013726: runtime/memory/ReserveMemory.java fails due to 'assert(bytes % os::vm_allocation_granularity() == 0) failed: reserve block size'
Summary: Fix regression test to work on all platforms
Reviewed-by: ctornqvi, dholmes

! src/share/vm/prims/whitebox.cpp
! test/runtime/memory/ReserveMemory.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 1a07e086ff28
Author:    dholmes
Date:      2013-05-21 19:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a07e086ff28

Merge


Changeset: 6bd680e9ea35
Author:    coleenp
Date:      2013-05-22 14:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6bd680e9ea35

8003421: NPG: Move oops out of InstanceKlass into mirror
Summary: Inject protection_domain, signers, init_lock into java_lang_Class
Reviewed-by: stefank, dholmes, sla

! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaInstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 699d9df07e59
Author:    ctornqvi
Date:      2013-05-23 17:39 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/699d9df07e59

8009576: Test returns ClassNotFoundException
Summary: Small classpath fix and move tests into open
Reviewed-by: mgerdin, zgu

+ test/runtime/Metaspace/FragmentMetaspace.java
+ test/runtime/Metaspace/FragmentMetaspaceSimple.java
+ test/runtime/Metaspace/classes/test/Empty.java
+ test/runtime/testlibrary/GeneratedClassLoader.java

Changeset: b7fa10a3a69a
Author:    sspitsyn
Date:      2013-05-23 23:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7fa10a3a69a

8014288: perf regression in nashorn JDK-8008448.js test after 8008511 changes
Summary: The fix of perf regression is to use method_idnum() for direct indexing into NMT
Reviewed-by: twisti, kvn, coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp

Changeset: cd83e1d98347
Author:    dcubed
Date:      2013-05-24 10:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd83e1d98347

Merge


Changeset: 6c138b9851fb
Author:    sspitsyn
Date:      2013-05-24 17:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c138b9851fb

8013945: CMS fatal error: must own lock MemberNameTable_lock
Summary: The "delete mnt" needs to grab MemberNameTable_lock if !SafepointSynchronize::is_at_safepoint()
Reviewed-by: sla, mgerdin, dholmes, jmasa
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/oops/instanceKlass.cpp

Changeset: 3970971c91e0
Author:    shade
Date:      2013-05-27 12:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3970971c91e0

8015270: @Contended: fix multiple issues in the layout code
Summary: field count handling fixed, has_nonstatic_fields invariant fixed, oop map overrun fixed; new asserts
Reviewed-by: kvn, dcubed, coleenp

! src/share/vm/classfile/classFileParser.cpp
+ test/runtime/contended/HasNonStatic.java
+ test/runtime/contended/OopMaps.java

Changeset: a213d425d87a
Author:    ctornqvi
Date:      2013-05-28 15:08 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a213d425d87a

8015329: Print reason for failed MiniDumpWriteDump() call
Summary: Printing both result from GetLastError and text representation of error. Also changed so that we produce dumps by default on client versions of Windows when running with a debug build. Also reviewed by peter.allwin at oracle.com
Reviewed-by: sla, dholmes

! src/os/windows/vm/os_windows.cpp

Changeset: 51af5fae397d
Author:    ccheung
Date:      2013-05-24 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/51af5fae397d

8015265: revise the fix for 8007037
Reviewed-by: sspitsyn, dholmes, dcubed

! src/share/vm/oops/constantPool.cpp

Changeset: 4cc7d4d5dc92
Author:    zgu
Date:      2013-05-28 08:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4cc7d4d5dc92

Merge


Changeset: 01c2bdd24bb5
Author:    shade
Date:      2013-05-28 19:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01c2bdd24bb5

8015493: runtime/contended/OopMaps.java fails with OutOfMemory
Summary: limit the memory footprint to dodge OutOfMemory errors.
Reviewed-by: dcubed, ctornqvi, iignatyev

! test/runtime/contended/OopMaps.java

Changeset: 9ea643afcaaf
Author:    dcubed
Date:      2013-05-28 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ea643afcaaf

Merge


Changeset: dcb062bea05b
Author:    jprovino
Date:      2013-05-28 11:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcb062bea05b

8013461: There is a symbol AsyncGetCallTrace in libjvm.symbols that does not exist in minimal/libjvm.a when DEBUG_LEVEL == release
Summary: AsyncGetCallTrace is needed in libjvm.symbols so that programs which reference it can build correctly.
Reviewed-by: dholmes, bobv

! make/excludeSrc.make
! src/share/vm/prims/forte.cpp

Changeset: fb14e9ed1594
Author:    jprovino
Date:      2013-05-28 11:32 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb14e9ed1594

8011064: Some tests have failed with SIGSEGV on arm-hflt on build b82
Summary: NMT_detail is only supported when frame pointers are not omitted (-fno-omit-frame-pointer).
Reviewed-by: dholmes, cjplummer

! src/share/vm/services/memTracker.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 9e954e8d9139
Author:    jprovino
Date:      2013-05-28 15:24 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e954e8d9139

Merge


Changeset: 9e86c5544295
Author:    jiangli
Date:      2013-05-30 13:19 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e86c5544295

Merge


Changeset: 0def34ab1c98
Author:    tamao
Date:      2013-05-21 16:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0def34ab1c98

8015007: Incorrect print format in error message for VM cannot allocate the requested heap
Summary: Correct the wrong print format in error message for VM cannot allocate the requested heap; and clean up the error message call in check_alignment()
Reviewed-by: brutisso, tschatzl
Contributed-by: tamao 

! src/share/vm/memory/universe.cpp

Changeset: 14d3f71f831d
Author:    tamao
Date:      2013-05-22 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/14d3f71f831d

8007762: Rename a bunch of methods in size policy across collectors
Summary: Rename: compute_generations_free_space() = compute_eden_space_size() + compute_old_gen_free_space(); update related logging messages
Reviewed-by: jmasa, johnc, tschatzl, brutisso
Contributed-by: tamao 

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp

Changeset: 0886b99a4d1b
Author:    jwilhelm
Date:      2013-05-24 14:16 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0886b99a4d1b

Merge


Changeset: eda078b01c65
Author:    stefank
Date:      2013-05-27 15:22 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eda078b01c65

8015268: NPG: 2.5% regression in young GC times on CRM Sales Opty
Summary: Split SystemDictionary and ClassLoaderDataGraph root processing to help load balancing.
Reviewed-by: tschatzl, johnc

! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp
! src/share/vm/memory/sharedHeap.cpp

Changeset: 95c00927be11
Author:    stefank
Date:      2013-05-27 12:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95c00927be11

8015428: Remove unused CDS support from StringTable
Summary: The string in StringTable is not used by CDS anymore. Remove the unnecessary code in preparation for 8015422: Large performance hit when the StringTable is walked twice in Parallel Scavenge
Reviewed-by: pliden, tschatzl, coleenp

! src/share/vm/classfile/symbolTable.cpp

Changeset: 8dbc025ff709
Author:    stefank
Date:      2013-05-27 12:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8dbc025ff709

8015422: Large performance hit when the StringTable is walked twice in Parallel Scavenge
Summary: Combine the calls to StringTable::unlink and StringTable::oops_do in Parallel Scavenge.
Reviewed-by: pliden, coleenp

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp

Changeset: f41a577cffb0
Author:    jwilhelm
Date:      2013-05-31 09:55 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f41a577cffb0

Merge


Changeset: b786c04b7be1
Author:    amurillo
Date:      2013-05-31 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b786c04b7be1

Merge


Changeset: 5a028ee56116
Author:    amurillo
Date:      2013-05-31 09:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a028ee56116

Added tag hs25-b35 for changeset b786c04b7be1

! .hgtags

Changeset: b7569f617285
Author:    amurillo
Date:      2013-05-31 10:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b7569f617285

8015690: new hotspot build - hs25-b36
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 5534bd30c151
Author:    jcoomes
Date:      2013-05-30 13:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5534bd30c151

6725714: par compact - add a table to speed up bitmap searches
Reviewed-by: jmasa, tschatzl

! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp

Changeset: 47bdfb3d010f
Author:    stefank
Date:      2013-05-30 10:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/47bdfb3d010f

8015486: PSScavenge::is_obj_in_young is unnecessarily slow with UseCompressedOops
Summary: Compare compressed oops to a compressed young gen boundary instead of uncompressing the oops before doing the young gen boundary check.
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp

Changeset: c20186fa611b
Author:    jwilhelm
Date:      2013-06-01 10:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c20186fa611b

Merge


Changeset: e72f7eecc96d
Author:    tschatzl
Date:      2013-05-28 09:32 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e72f7eecc96d

8013895: G1: G1SummarizeRSetStats output on Linux needs improvemen
Summary: Fixed the output of G1SummarizeRSetStats: too small datatype for the number of concurrently processed cards, added concurrent remembered set thread time retrieval for Linux and Windows (BSD uses os::elapsedTime() now), and other cleanup. The information presented during VM operation is now relative to the previous output, not always cumulative if G1SummarizeRSetStatsPeriod > 0. At VM exit, the code prints a cumulative summary.
Reviewed-by: johnc, jwilhelm

! make/excludeSrc.make
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
+ src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
+ src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp
+ test/gc/g1/TestSummarizeRSetStats.java

Changeset: 3a4805ad0005
Author:    johnc
Date:      2013-06-04 10:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a4805ad0005

8015244: G1: Verification after a full GC is incorrectly placed.
Summary: In a full GC, move the verification after the GC to after RSet rebuilding. Verify RSet entries during a full GC under control of a flag.
Reviewed-by: tschatzl, brutisso

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: 87c64c0438fb
Author:    tamao
Date:      2013-06-03 14:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/87c64c0438fb

6976350: G1: deal with fragmentation while copying objects during GC
Summary: Create G1ParGCAllocBufferContainer to contain two buffers instead of previously using one buffer, in order to hold the first priority buffer longer. Thus, when some large objects hits the value of free space left in the first priority buffer it has an alternative to fit in the second priority buffer while the first priority buffer is given more chances to try allocating smaller objects. Overall, it will improve heap space efficiency.
Reviewed-by: johnc, jmasa, brutisso
Contributed-by: tamao 

! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: 2f7a31318b84
Author:    johnc
Date:      2013-06-04 14:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f7a31318b84

Merge


Changeset: a1ebd310d5c1
Author:    iklam
Date:      2013-05-28 16:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1ebd310d5c1

8014912: Restore PrintSharedSpaces functionality after NPG
Summary: Added dumping of object sizes in CDS archive, sorted by MetaspaceObj::Type
Reviewed-by: coleenp, acorn

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/oops/annotations.cpp
! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/methodCounters.cpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/symbol.cpp
! src/share/vm/utilities/array.hpp

Changeset: fe00365c8f31
Author:    sspitsyn
Date:      2013-05-30 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe00365c8f31

8015436: compiler/ciReplay/TestSA.sh fails with assert() index is out of bounds
Summary: The InstanceKlass _initial_method_idnum value must be adjusted if overpass methods are added.
Reviewed-by: twisti, kvn
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/classfile/defaultMethods.cpp
+ test/compiler/8015436/Test8015436.java

Changeset: a589c78a8811
Author:    rbackman
Date:      2013-05-31 13:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a589c78a8811

8014709: Constructor.getAnnotatedReturnType() returns empty AnnotatedType
Reviewed-by: stefank, rbackman
Contributed-by: Joel Borggren-Franck 

! src/share/vm/runtime/reflection.cpp
! test/runtime/8007320/ConstMethodTest.java

Changeset: efe8b7d64424
Author:    ctornqvi
Date:      2013-05-31 20:24 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/efe8b7d64424

6726963: multi_allocate() call does not CHECK_NULL and causes crash in fastdebug bits
Summary: Using CHECK_NULL when calling multi_allocate() from the corresponding reflection code; added test for this condition
Reviewed-by: dholmes, minqi
Contributed-by: Mikhailo Seledtsov 

! src/share/vm/runtime/reflection.cpp
+ test/runtime/memory/MultiAllocateNullCheck.java

Changeset: 532c55335fb6
Author:    dcubed
Date:      2013-06-01 09:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/532c55335fb6

Merge


Changeset: 4552a7633a07
Author:    hseigel
Date:      2013-06-03 10:00 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4552a7633a07

8015385: Remove RelaxAccessControlCheck for JDK 8 bytecodes
Summary: Check bytecode versions along with RelaxAccessControlCheck version
Reviewed-by: dholmes, acorn

! src/share/vm/classfile/verifier.hpp
! src/share/vm/runtime/reflection.cpp

Changeset: e7d29a019a3c
Author:    sspitsyn
Date:      2013-06-03 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7d29a019a3c

8014052: JSR292: assert(end_offset == next_offset) failed: matched ending
Summary: A call to the finalize_operands_merge() must be unconditional
Reviewed-by: kvn, twisti
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 2f004f9dc9e1
Author:    sspitsyn
Date:      2013-06-04 01:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f004f9dc9e1

8015803: Test8015436.java fails 'can not access a member of class Test8015436 with modifiers "public static"'
Summary: Newly added test has an issue: the main class must be public
Reviewed-by: kvn, jbachorik, coleenp
Contributed-by: serguei.spitsyn at oracle.com

! test/compiler/8015436/Test8015436.java

Changeset: 04551f4dbdb9
Author:    nloodin
Date:      2013-06-05 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04551f4dbdb9

Merge


Changeset: 62e7bac9524f
Author:    dcubed
Date:      2013-06-04 19:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62e7bac9524f

8010257: remove unused thread-local variables _ScratchA and _ScratchB
Summary: Remove dead code.
Reviewed-by: twisti, coleenp

! src/share/vm/runtime/thread.hpp

Changeset: 6bf8b8bb7c19
Author:    hseigel
Date:      2013-06-05 14:12 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6bf8b8bb7c19

8009302: Mac OS X: JVM crash on infinite recursion on Appkit Thread
Summary: Use SA_ONSTACK flag to ensure signal gets delivered properly.
Reviewed-by: dholmes, coleenp
Contributed-by: gerard.ziemski at oracle.com

! src/os/bsd/vm/os_bsd.cpp

Changeset: f8c8cace25ad
Author:    dcubed
Date:      2013-06-06 05:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8c8cace25ad

Merge

! src/os/bsd/vm/os_bsd.cpp

Changeset: 320b4e0f0892
Author:    roland
Date:      2013-05-30 11:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/320b4e0f0892

8015585: Missing regression test for 8011771
Summary: missing regression test
Reviewed-by: kvn

+ test/compiler/8011771/Test8011771.java

Changeset: f15fe46d8c00
Author:    twisti
Date:      2013-05-30 08:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f15fe46d8c00

8015266: fix some -Wsign-compare warnings in adlc
Reviewed-by: kvn

! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/dict2.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/output_c.cpp

Changeset: 28e5aed7f3a6
Author:    roland
Date:      2013-05-31 14:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28e5aed7f3a6

8009981: nashorn tests fail with -XX:+VerifyStack
Summary: nmethod::preserve_callee_argument_oops() must take appendix into account.
Reviewed-by: kvn, twisti

! src/share/vm/code/nmethod.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 83dcb116fdb1
Author:    kvn
Date:      2013-05-31 13:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83dcb116fdb1

8015441: runThese crashed with assert(opcode == Op_ConP || opcode == Op_ThreadLocal || opcode == Op_CastX2P ..) failed: sanity
Summary: Relax the assert to accept any raw ptr types.
Reviewed-by: roland

! src/share/vm/opto/escape.cpp

Changeset: c07dd9be16e8
Author:    anoll
Date:      2013-05-31 06:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c07dd9be16e8

8013496: Code cache management command line options work only in special order. Another order of arguments does not deliver the second parameter to the jvm.
Summary: Moved check that ReservedCodeCacheSize >= InitialCodeCacheSize to Arguments::check_vm_args_consistency(). As a result, the ordering in which the two parameters are given to the VM is not relevant. Added a regression test.
Reviewed-by: kvn, twisti

! src/share/vm/runtime/arguments.cpp
+ test/compiler/8013496/Test8013496.sh

Changeset: 603ca7e51354
Author:    roland
Date:      2013-04-24 11:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/603ca7e51354

8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292
Summary: ConstMethod::max_stack() doesn't account for JSR 292 appendix.
Reviewed-by: kvn

! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/opto/matcher.cpp

Changeset: 813f26e34135
Author:    anoll
Date:      2013-06-03 08:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/813f26e34135

8013329: File leak in hotspot/src/share/vm/compiler/compileBroker.cpp
Summary: Added calling of the destructor of CompileLog so that files are closed. Added/moved memory allocation/deallocation of the string that contains the name of the log file to class CompileLog.
Reviewed-by: kvn, roland

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp

Changeset: b274ac1dbe11
Author:    adlertz
Date:      2013-06-03 12:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b274ac1dbe11

8005956: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block
Summary: Disable re-materialization of reaching definitions (which have live inputs) for phi nodes when spilling.
Reviewed-by: twisti, kvn

! src/share/vm/opto/reg_split.cpp

Changeset: 770e91e578a6
Author:    kvn
Date:      2013-06-03 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/770e91e578a6

Merge


Changeset: 075ea888b039
Author:    morris
Date:      2013-06-04 12:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/075ea888b039

8010724: [parfait] Null pointer dereference in hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
Summary: added guarantee()
Reviewed-by: kvn

! src/share/vm/c1/c1_LIRGenerator.cpp

Changeset: 2cb5d5f6d5e5
Author:    simonis
Date:      2013-06-04 22:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2cb5d5f6d5e5

8015252: Enable HotSpot build with Clang
Reviewed-by: twisti, dholmes, kvn

! make/bsd/makefiles/adlc.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/adlc.make
! make/linux/makefiles/gcc.make
! src/os/bsd/vm/os_bsd.cpp
! src/os_cpu/linux_x86/vm/linux_x86_32.s
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp

Changeset: 609aad72004a
Author:    anoll
Date:      2013-06-06 09:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/609aad72004a

8014246: remove assert to catch access to object headers in index_oop_from_field_offset_long
Reviewed-by: twisti, jrose

! src/share/vm/prims/unsafe.cpp

Changeset: ef1818846c22
Author:    kvn
Date:      2013-06-06 11:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef1818846c22

Merge

! src/os/bsd/vm/os_bsd.cpp

Changeset: 3c78a14da19d
Author:    amurillo
Date:      2013-06-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c78a14da19d

Merge

! .hgtags

Changeset: 1beed1f6f9ed
Author:    amurillo
Date:      2013-06-07 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1beed1f6f9ed

Added tag hs25-b36 for changeset 3c78a14da19d

! .hgtags

Changeset: 3a353050e85a
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a353050e85a

Added tag jdk8-b94 for changeset 1beed1f6f9ed

! .hgtags



From peter.levart at gmail.com  Mon Jun 17 06:55:04 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 17 Jun 2013 08:55:04 +0200
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCBEE1.4040300@univ-mlv.fr>
	<06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>
Message-ID: <51BEB2C8.5000906@gmail.com>

On 06/15/2013 09:59 PM, Nick Williams wrote:
> On Jun 15, 2013, at 2:22 PM, Remi Forax wrote:
>
>> Could you be a little more clear why you need a class for your logging API, exactly, why the class name is not enough for logging purpose ?
> Certainly. Log4j 2 offers "extended stack trace" patterns. When exceptions or stack traces are logged, or when displaying the location that the logging statement originated from, the stack trace/log also reveals the resource (JAR file, directory, etc.) that the class was loaded from and the implementation version from the package the class is in. This helps reveal possible class loading issues (among other things), which can be an extremely valuable tool when troubleshooting problems with an application.
>
> Log4j 2 accomplishes this by getting the class associated with a StackTraceElement (as outlined below), and then 1) getting the Package from the Class and the version from the Package, and 2) getting the ProtectionDomain from the Class, getting the CodeSource from the ProtectionDomain, and getting the JAR/URL from the CodeSource. The last two parts are easy. It's getting the Class from the StackTrace that is extremely inefficient if not done right. Java 8 took away the best way we had found to do that (which, admittedly, was because we were relying on a non-standard class, which isn't recommended).
>

On 06/17/2013 08:12 AM, Peter Levart wrote:
> New API could be entirely unrelated to Throwable, if there was support 
> for it in native code. Since there would have to be changes to the 
> native code anyway to support this, why not create a separate API? 

If I understand this correctly, one part of your code is displaying the 
"resource location" of each method's declaring class in the stack trace 
when such "extended stack trace" is configured. Therefore you need this 
API to capture the class-enriched-stack-trace at the time the Throwable 
instance is constructed. No special Throwable-unrelated API to return 
the stack trace would be suitable for this purpose then.

But for the purpose of displaying the "resource location" of the class 
invoking the logging API, you don't need the entire stack trace, just 
the immediate caller class, right? When @CallerSensitive internal 
annotation was introduced (and Reflection.getCallerClass(int frames) was 
dropped), there was some debate about possible introduction of public 
API that could be used to reveal the caller's class. Perhaps there's 
still time to create such API for JDK8? At least one part of your 
logging functionality would be covered with such API.

Suppose the API to obtain the immediate caller class (j.l.Class object) 
was public and fast, so you could do that for each call to the logging 
API eagerly (after initial check for logging level). Now, could you 
delay the evaluation of "extended stack trace" pattern to the latest 
time possible, when you must format the stack-trace? Would calling 
Class.forName(name, false, classLoader) for each individual 
StackTraceElement, using the ClassLoader of the caller class, still 
present a performance problem? You would only get locations for classes 
that the caller has access to, so no inaccessible information could be 
revealed.

Regards, Peter



From lana.steuck at oracle.com  Mon Jun 17 06:32:27 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Mon, 17 Jun 2013 06:32:27 +0000
Subject: hg: jdk8/tl/jdk: 36 new changesets
Message-ID: <20130617063953.5C3EF4825D@hg.openjdk.java.net>

Changeset: 583e6dec1ed7
Author:    erikj
Date:      2013-05-29 14:01 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/583e6dec1ed7

8013489: New build system does not run codesign on SA-related launchers on OS X
Reviewed-by: sla, tbell

! makefiles/CompileLaunchers.gmk

Changeset: d8c97d6772cd
Author:    erikj
Date:      2013-05-30 09:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8c97d6772cd

Merge


Changeset: bc3a17982aae
Author:    erikj
Date:      2013-05-31 14:05 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc3a17982aae

7195481: FDS: debuginfo file for libjdwp.so is missed
Reviewed-by: tbell

! make/jpda/back/Makefile
! makefiles/CompileNativeLibraries.gmk

Changeset: c50add191a39
Author:    katleman
Date:      2013-06-04 11:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c50add191a39

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: 16003f414ca3
Author:    katleman
Date:      2013-06-04 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16003f414ca3

8015644: makefile changes to allow integration of new features
Reviewed-by: tbell, erikj, dholmes
Contributed-by: amy.y.wang at oracle.com

! makefiles/Images.gmk

Changeset: 691d6c6cd332
Author:    katleman
Date:      2013-06-05 15:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/691d6c6cd332

6983966: remove lzma and upx from repository JDK8
Reviewed-by: tbell, paulk, ngthomas

! make/common/Defs-windows.gmk

Changeset: 7b757d567346
Author:    katleman
Date:      2013-06-06 09:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b757d567346

Added tag jdk8-b93 for changeset 691d6c6cd332

! .hgtags

Changeset: fd377533608b
Author:    andrew
Date:      2013-05-30 16:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd377533608b

8011693: Remove redundant fontconfig files
Summary: Remove unused fontconfig files from OpenJDK GNU/Linux builds
Reviewed-by: andrew, prr
Contributed-by: Jiri Vanek 

! make/sun/awt/Makefile
! makefiles/GendataFontConfig.gmk
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties

Changeset: b9b73bf450a4
Author:    bae
Date:      2013-05-31 14:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9b73bf450a4

8015606: Text is not rendered correctly if destination buffer is custom
Reviewed-by: prr, vadim

! src/share/classes/sun/java2d/loops/MaskFill.java
+ test/sun/java2d/loops/RenderToCustomBufferTest.java

Changeset: 0a17344d074e
Author:    prr
Date:      2013-05-31 09:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a17344d074e

8015556: [macosx] surrogate pairs do not render properly.
Reviewed-by: bae, jchen

! src/macosx/classes/sun/font/CCharToGlyphMapper.java
+ test/java/awt/FontClass/SurrogateTest/SuppCharTest.java

Changeset: 3af3981dee11
Author:    lana
Date:      2013-06-05 09:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3af3981dee11

Merge

- test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh

Changeset: 768fcc36182a
Author:    anthony
Date:      2013-05-30 18:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/768fcc36182a

8015303: [macosx] Application launched via custom URL Scheme does not receive URL
Summary: Make copies of event parameters
Reviewed-by: anthony, swingler, serb
Contributed-by: James Tomson 

! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m

Changeset: 8472c148688c
Author:    ant
Date:      2013-05-30 18:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8472c148688c

8013424: Regression: java.awt.datatransfer.FlavorListeners not notified on Linux/Java 7
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XClipboard.java

Changeset: 56512cfccef9
Author:    ant
Date:      2013-05-30 18:31 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56512cfccef9

8013773: requestFocusInWindow to a disabled component prevents window of getting focused
Reviewed-by: leonidr, alexsch

! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
+ test/java/awt/Focus/ResetMostRecentFocusOwnerTest/ResetMostRecentFocusOwnerTest.java

Changeset: b0eab0f8b503
Author:    anthony
Date:      2013-05-31 14:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0eab0f8b503

8013189: JMenuItems draw behind TextArea
Summary: Untie XTextAreaPeer internal components from the TextArea parent to prevent its invalidation. I.e. force the java.awt.smartInvalidate=true locally.
Reviewed-by: art, serb

! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java
+ test/java/awt/TextArea/Mixing/TextAreaMixing.java

Changeset: 481476e941fd
Author:    ant
Date:      2013-05-31 15:56 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/481476e941fd

8015589: Test java/awt/Window/Grab/GrabTest.java fails on MacOSX
Reviewed-by: anthony

! test/java/awt/Window/Grab/GrabTest.java

Changeset: 611f8664c96c
Author:    malenkov
Date:      2013-05-31 18:25 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/611f8664c96c

8013557: XMLEncoder in 1.7 can't encode objects initialized in no argument constructor
Reviewed-by: alexsch

! src/share/classes/java/beans/XMLEncoder.java
+ test/java/beans/XMLEncoder/Test6989223.java
+ test/java/beans/XMLEncoder/Test7080156.java
+ test/java/beans/XMLEncoder/Test8013557.java

Changeset: a4356b90f57d
Author:    vkarnauk
Date:      2013-05-31 18:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4356b90f57d

7068740: If you wrap a JTable in a JLayer you can't use the page up and page down cmds
Reviewed-by: alexsch, alexp

! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java
+ test/javax/swing/JTable/7068740/bug7068740.java

Changeset: 791fd2ef87b3
Author:    vkarnauk
Date:      2013-05-31 19:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/791fd2ef87b3

6436314: Vector could be created with appropriate size in DefaultComboBoxModel
Reviewed-by: alexsch, alexp

! src/share/classes/javax/swing/DefaultComboBoxModel.java

Changeset: ae4683a6b860
Author:    pchelko
Date:      2013-06-03 10:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae4683a6b860

8015477: Support single threaded AWT/FX mode.
Reviewed-by: ant, anthony

! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/CDropTargetContextPeer.m
! src/macosx/native/sun/awt/LWCToolkit.m
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/sun/awt/AWTAccessor.java
+ src/share/classes/sun/awt/FwDispatcher.java

Changeset: 43f82f573c01
Author:    alitvinov
Date:      2013-06-03 14:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43f82f573c01

7151823: The test incorrectly recognizing OS
Reviewed-by: serb, alexp

! test/javax/swing/JTabbedPane/4624207/bug4624207.java

Changeset: d378104e52e3
Author:    anthony
Date:      2013-06-03 16:27 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d378104e52e3

8015500: Prevent sending multiple WINDOW_CLOSED events for already disposed windows
Reviewed-by: anthony, serb
Contributed-by: Jose Luis Martin 

! src/share/classes/java/awt/Window.java
+ test/java/awt/Window/WindowClosedEvents/WindowClosedEventOnDispose.java

Changeset: 9a8e0140123a
Author:    alitvinov
Date:      2013-06-03 16:37 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a8e0140123a

6337518: Null Arrow Button Throws Exception in BasicComboBoxUI
Reviewed-by: alexp, alexsch

! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java
+ test/javax/swing/JComboBox/6337518/bug6337518.java

Changeset: 8b274eccd94a
Author:    mcherkas
Date:      2013-06-05 14:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b274eccd94a

8015375: Edits to text components hang for clipboard access
Reviewed-by: art, anthony
Contributed-by: Dmitry Markov 

! src/solaris/native/sun/xawt/XlibWrapper.c

Changeset: 1390369d4457
Author:    vkarnauk
Date:      2013-06-05 16:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1390369d4457

8015425: [macosx] A follow-up for the fix 8010721
Reviewed-by: serb, anthony

! src/macosx/native/sun/awt/AWTWindow.m

Changeset: a4af3d10d19e
Author:    ant
Date:      2013-06-05 17:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4af3d10d19e

8015339: Correct a wording in javadoc of java.awt.ContainerOrderFocusTraversalPolicy
Reviewed-by: art, anthony

! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java

Changeset: 6802f71a5eb2
Author:    malenkov
Date:      2013-06-05 18:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6802f71a5eb2

8013370: Null pointer exception when adding more than 9 accelators to a JMenuBar
Reviewed-by: serb

! src/share/classes/javax/swing/KeyboardManager.java
+ test/javax/swing/KeyboardManager/8013370/Test8013370.java

Changeset: e246bc03c8cb
Author:    lana
Date:      2013-06-05 00:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e246bc03c8cb

Merge

- test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh

Changeset: 3e904a3f3c9f
Author:    lana
Date:      2013-06-05 09:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e904a3f3c9f

Merge


Changeset: f272934d41fb
Author:    lana
Date:      2013-06-05 12:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f272934d41fb

Merge


Changeset: 388b4d4cae3b
Author:    lana
Date:      2013-06-05 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/388b4d4cae3b

Merge

- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

Changeset: 080449feeca9
Author:    lana
Date:      2013-06-10 17:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/080449feeca9

Merge

- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

Changeset: e833fa13dce3
Author:    erikj
Date:      2013-06-11 13:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e833fa13dce3

8010785: JDK 8 build on Linux fails with new build mechanism
Reviewed-by: dholmes, tbell

! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk
! makefiles/Import.gmk
! makefiles/Setup.gmk

Changeset: 51479fa56b7c
Author:    erikj
Date:      2013-06-12 10:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51479fa56b7c

Merge


Changeset: 992b39afdcb9
Author:    katleman
Date:      2013-06-13 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/992b39afdcb9

Added tag jdk8-b94 for changeset 51479fa56b7c

! .hgtags

Changeset: bad604b15314
Author:    lana
Date:      2013-06-16 22:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bad604b15314

Merge

- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties



From nicholas+openjdk at nicholaswilliams.net  Mon Jun 17 07:20:35 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 17 Jun 2013 02:20:35 -0500
Subject: Thoughts on adding getElementClass() method to StackTraceElement?
In-Reply-To: <51BEB2C8.5000906@gmail.com>
References: <5BE6D6E8-2AB9-474F-B92B-2D3459AC072D@nicholaswilliams.net>
	<51BCBEE1.4040300@univ-mlv.fr>
	<06068BC0-50BC-4FCE-9D73-6E4D7F00D47C@nicholaswilliams.net>
	<51BEB2C8.5000906@gmail.com>
Message-ID: <419571AF-3AFC-4652-BA13-A5E99A26AADC@nicholaswilliams.net>


On Jun 17, 2013, at 1:55 AM, Peter Levart wrote:

> On 06/15/2013 09:59 PM, Nick Williams wrote:
>> On Jun 15, 2013, at 2:22 PM, Remi Forax wrote:
>> 
>>> Could you be a little more clear why you need a class for your logging API, exactly, why the class name is not enough for logging purpose ?
>> Certainly. Log4j 2 offers "extended stack trace" patterns. When exceptions or stack traces are logged, or when displaying the location that the logging statement originated from, the stack trace/log also reveals the resource (JAR file, directory, etc.) that the class was loaded from and the implementation version from the package the class is in. This helps reveal possible class loading issues (among other things), which can be an extremely valuable tool when troubleshooting problems with an application.
>> 
>> Log4j 2 accomplishes this by getting the class associated with a StackTraceElement (as outlined below), and then 1) getting the Package from the Class and the version from the Package, and 2) getting the ProtectionDomain from the Class, getting the CodeSource from the ProtectionDomain, and getting the JAR/URL from the CodeSource. The last two parts are easy. It's getting the Class from the StackTrace that is extremely inefficient if not done right. Java 8 took away the best way we had found to do that (which, admittedly, was because we were relying on a non-standard class, which isn't recommended).
>> 
> 
> On 06/17/2013 08:12 AM, Peter Levart wrote:
>> New API could be entirely unrelated to Throwable, if there was support for it in native code. Since there would have to be changes to the native code anyway to support this, why not create a separate API? 
> 
> If I understand this correctly, one part of your code is displaying the "resource location" of each method's declaring class in the stack trace when such "extended stack trace" is configured. Therefore you need this API to capture the class-enriched-stack-trace at the time the Throwable instance is constructed. No special Throwable-unrelated API to return the stack trace would be suitable for this purpose then.

Yes, this is correct. This is the primary use case that needs satisfying.

> But for the purpose of displaying the "resource location" of the class invoking the logging API, you don't need the entire stack trace, just the immediate caller class, right? When @CallerSensitive internal annotation was introduced (and Reflection.getCallerClass(int frames) was dropped), there was some debate about possible introduction of public API that could be used to reveal the caller's class. Perhaps there's still time to create such API for JDK8? At least one part of your logging functionality would be covered with such API.

I would love for this to be part of the public API, but since it's annotation-based we wouldn't be able to use it for probably six or seven years. For the foreseeable future Log4j must compile on Java 6.

> Suppose the API to obtain the immediate caller class (j.l.Class object) was public and fast, so you could do that for each call to the logging API eagerly (after initial check for logging level). Now, could you delay the evaluation of "extended stack trace" pattern to the latest time possible, when you must format the stack-trace? Would calling Class.forName(name, false, classLoader) for each individual StackTraceElement, using the ClassLoader of the caller class, still present a performance problem?

Yes. Our _primary_ concern here is locating the source information for Throwable stack traces. (In fact, if you want, just forget about the source info for the calling class. That's easy. Let's focus JUST on Throwables.) Class.forName() is orders of magnitude slower that SecurityManager#getClassContext() and Reflection#getCallerClass(). And that's not even considering the fact that getClassContext() and getCallerClass() can only fill in _part_ of the stack trace (because they don't line up; one is from Throwable, the other is from current stack). If we could actually obtain the entire stack trace's source info without Class.forName(), it would be even faster. That's why I thought the _simplest_ approach would be to add the getElementClass() method to StackTraceElement ... it works everywhere.

If the proposed solution is a StackFrame class instead, that's fine by me. I just need to be able to get the StackFrame[] for a Throwable.

Nick

From aleksey.shipilev at oracle.com  Mon Jun 17 08:06:18 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 12:06:18 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BE1591.8010901@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com>
Message-ID: <51BEC37A.2010303@oracle.com>

On 06/16/2013 11:44 PM, Alan Bateman wrote:
> On 13/06/2013 12:47, Aleksey Shipilev wrote:
>> Friendly reminder for the reviewers.
>>
>> On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
>>> This is the follow-up on the issue Doug identified:
>>>   
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
>>>
>>>
>>> I had reworked the patch, webrev is here:
>>>    http://cr.openjdk.java.net/~shade/8016236/webrev.01/
>> The current webrev is here:
>>    http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>>
> I'm just catching up on this thread, webrev.02 looks very good to me. I
> can sponsor it.

Thanks! I'll appreciate this.

> One comment on ClassRepositoryHolder is that it's "yet another class"
> (we have a proliferation of holder classes since we started using this
> idiom). It makes me wonder if it might be better to move the constant to
> ClassRepository.

Ok, makes sense. I moved it to ClassRepository itself. Given we have the
ClassRepository field in Class, the static initialization will be
performed on the first class load. I have no problems having it public,
since it is protected enough from the external modifications.

The new webrev is here:
  http://cr.openjdk.java.net/~shade/8016236/webrev.03/

Testing:
  - Linux/x86_64/release build OK
  - Linux/x86_64/release passes java/lang/reflect jtreg
  - microbenchmark scores are still intact

-Aleksey.


From daniel.fuchs at oracle.com  Mon Jun 17 08:17:31 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Jun 2013 10:17:31 +0200
Subject: RFR (jaxp): 8016133 : Regression: diff. behavior with user-defined
	SAXParser
In-Reply-To: <51B69B3D.1070707@oracle.com>
References: <51B69B3D.1070707@oracle.com>
Message-ID: <51BEC61B.4090709@oracle.com>

Hi Joe,

Looks good to me. Not a reviewer - as you know ;-)

-- daniel

On 6/11/13 5:36 AM, huizhe wang wrote:
> Hi,
>
> This is a quick fix on a regression caused by a previous patch. The
> XMLReaderFactory uses a class variable (_jarread) to indicate if service
> file has already been read. Along with this variable, there was another
> (clsFromJar ) that caches the classname if found in a service file. The
> 2nd variable and its use were accidentally removed. As a result, the
> following code would return the 3rd party impl on first call but then
> fall back to the default impl on subsequent calls because reading
> service file was skipped when _jarread is true:
>              XMLReader reader = XMLReaderFactory.createXMLReader();
>              System.out.println("1:" + reader.getClass().getName());
>
>              XMLReader reader2 = XMLReaderFactory.createXMLReader();
>              System.out.println("2:" + reader2.getClass().getName());
>
> The fix is simply recover the original code.  Here's the webrev:
>
> http://cr.openjdk.java.net/~joehw/jdk8/8016133/webrev/
>
> Thanks,
> Joe



From nicholas+openjdk at nicholaswilliams.net  Mon Jun 17 08:40:52 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 17 Jun 2013 03:40:52 -0500
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: 
References: 
Message-ID: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>


On Jun 15, 2013, at 1:34 PM, Nick Williams wrote:

> Currently, MessageFormat /only/ supports SimpleDateFormat and instances of java.util.Date or java.util.Calendar for date/time values. Because of this, it's impossible to use Java 8 date/time types with any of the i18n and localization tools.
> 
> MessageFormat really needs support for types in java.time. Should I file a bug somewhere about this (where?), or is this message enough to get this going? I'm not even sure how it should work. I'm not sure how MessageFormat can know whether a SimpleDateFormat string or a DateTimeFormatter string is being supplied. Possibly, validation of the format string must be delayed until either a Date/Calendar or a java.time type is supplied for formatting.

Looks like there _also_ needs to be java.time support in JAXB. I have a POJO with an @XmlElement "lastModified" of type java.time.Instant, and it just gets printed out  (the value is ignored). It should be printed out ISO 8601-formatted.

From aleksey.shipilev at oracle.com  Mon Jun 17 09:00:37 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 13:00:37 +0400
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended on TLR
	fields
Message-ID: <51BED035.30300@oracle.com>

Hi,

This is the respin of the RFE filed a month ago:
  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html

The webrev is here:
  http://cr.openjdk.java.net/~shade/8014233/webrev.02/

Testing:
  - JPRT build passes
  - Linux x86_64/release passes jdk/java/lang jtreg
  - vm.quick.testlist, vm.quick-gc.testlist on selected platforms
  - microbenchmarks, see below

The rationale follows.

After we merged ThreadLocalRandom state in the thread, we are now
missing the padding to prevent false sharing on those heavily-updated
fields. While the Thread is already large enough to separate two TLR
states for two distinct threads, we can still get the false sharing with
other thread fields.

There is the benchmark showcasing this:
  http://cr.openjdk.java.net/~shade/8014233/threadbench.zip

There are two test cases: first one is only calling its own TLR with
nextInt() and then the current thread's ID, another test calls *another*
thread ID, thus inducing the false sharing against another thread's TLR
state.

On my 2x2 i5 laptop, running Linux x86_64:
  same:    355 +- 1 ops/usec
  other:   100 +- 5 ops/usec

Note the decrease in throughput because of the false sharing.

With the patch:
  same:    359 +- 1 ops/usec
  other:   356 +- 1 ops/usec

Note the performance is back. We want to evade these spurious decreases
in performance, due to either unlucky memory layout, or the user code
(un)intentionally ruining the cache line locality for the updater thread.

Thanks,
-Aleksey.


From paul.sandoz at oracle.com  Mon Jun 17 09:18:57 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 17 Jun 2013 11:18:57 +0200
Subject: mercurial mq  Re: RFR 8010325 : Remove hash32() method and
	hash32 int field from java.lang.String
In-Reply-To: 
References: <51B7896A.70109@oracle.com>
	
	<51B934A9.8000103@oracle.com> <51BA21B0.8030008@oracle.com>
	
Message-ID: <6E71BF94-59D6-4757-896F-127AA5DA5289@oracle.com>


On Jun 14, 2013, at 10:36 PM, Martin Buchholz  wrote:

> On Thu, Jun 13, 2013 at 12:46 PM, Brent Christian <
> brent.christian at oracle.com> wrote:
> 
>> On 6/12/13 7:55 PM, David Holmes wrote:
>> 
>>> Something of an aside but ...
>>> 
>>> On 13/06/2013 3:45 AM, Martin Buchholz wrote:
>>> 
>>>> Hi Brent,
>>>> 
>>>> Thanks for doing this.
>>>> 
>>>> Your webrev does not include mercurial changeset information, which I
>>>> think
>>>> is supported by recent webrevs.
>>>> 
>>> 
>>> Given the changeset has to be created after the review is complete
>>> most/many people will not have a changeset prepared at review time.
>>> 
>> 
>> That's it exactly.  If at all possible, I don't commit until the code has
>> completed code review.  I tell webrev to do its thing based on modified
>> files, rather than outgoing changesets.
> 
> 
> Hmmm.... I've been using mq for so long it's hard for me to imagine working
> without it.
> 
> It allows others to review the mercurial changeset metadata, which is also
> the best summary to decide whether to review further.


+1 

mq is the best way i have found to keep multiple patches in flight either in the same queue or using multiple queues, and avoid those annoying merge commits.

I wish there were better tooling support in IDEs for it.

Paul.



From scolebourne at joda.org  Mon Jun 17 09:20:48 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 17 Jun 2013 10:20:48 +0100
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: <6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
References: 
	<6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
Message-ID: 

The standard JDK bug tracker should be used to keep track of these.

For info, Oracle is in control of integration of JSR-310 into other
APIs, not JSR-310.

Stephen


On 17 June 2013 09:40, Nick Williams
 wrote:
>
> On Jun 15, 2013, at 1:34 PM, Nick Williams wrote:
>
>> Currently, MessageFormat /only/ supports SimpleDateFormat and instances of java.util.Date or java.util.Calendar for date/time values. Because of this, it's impossible to use Java 8 date/time types with any of the i18n and localization tools.
>>
>> MessageFormat really needs support for types in java.time. Should I file a bug somewhere about this (where?), or is this message enough to get this going? I'm not even sure how it should work. I'm not sure how MessageFormat can know whether a SimpleDateFormat string or a DateTimeFormatter string is being supplied. Possibly, validation of the format string must be delayed until either a Date/Calendar or a java.time type is supplied for formatting.
>
> Looks like there _also_ needs to be java.time support in JAXB. I have a POJO with an @XmlElement "lastModified" of type java.time.Instant, and it just gets printed out  (the value is ignored). It should be printed out ISO 8601-formatted.


From paul.sandoz at oracle.com  Mon Jun 17 09:45:07 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 17 Jun 2013 11:45:07 +0200
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BEC37A.2010303@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
Message-ID: 


On Jun 17, 2013, at 10:06 AM, Aleksey Shipilev  wrote:

> On 06/16/2013 11:44 PM, Alan Bateman wrote:
>> On 13/06/2013 12:47, Aleksey Shipilev wrote:
>>> Friendly reminder for the reviewers.
>>> 
>>> On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
>>>> This is the follow-up on the issue Doug identified:
>>>> 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
>>>> 
>>>> 
>>>> I had reworked the patch, webrev is here:
>>>>   http://cr.openjdk.java.net/~shade/8016236/webrev.01/
>>> The current webrev is here:
>>>   http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>>> 
>> I'm just catching up on this thread, webrev.02 looks very good to me. I
>> can sponsor it.
> 
> Thanks! I'll appreciate this.
> 
>> One comment on ClassRepositoryHolder is that it's "yet another class"
>> (we have a proliferation of holder classes since we started using this
>> idiom). It makes me wonder if it might be better to move the constant to
>> ClassRepository.
> 
> Ok, makes sense. I moved it to ClassRepository itself. Given we have the
> ClassRepository field in Class, the static initialization will be
> performed on the first class load. I have no problems having it public,
> since it is protected enough from the external modifications.
> 
> The new webrev is here:
>  http://cr.openjdk.java.net/~shade/8016236/webrev.03/
> 

Looks good to me.

Paul.

> Testing:
>  - Linux/x86_64/release build OK
>  - Linux/x86_64/release passes java/lang/reflect jtreg
>  - microbenchmark scores are still intact
> 
> -Aleksey.



From nicholas+openjdk at nicholaswilliams.net  Mon Jun 17 10:05:35 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 17 Jun 2013 05:05:35 -0500
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: 
References: 
	<6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
	
Message-ID: <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net>

Thanks. I have filed two different bugs for these two different problems.

On Jun 17, 2013, at 4:20 AM, Stephen Colebourne wrote:

> The standard JDK bug tracker should be used to keep track of these.
> 
> For info, Oracle is in control of integration of JSR-310 into other
> APIs, not JSR-310.
> 
> Stephen
> 
> 
> On 17 June 2013 09:40, Nick Williams
>  wrote:
>> 
>> On Jun 15, 2013, at 1:34 PM, Nick Williams wrote:
>> 
>>> Currently, MessageFormat /only/ supports SimpleDateFormat and instances of java.util.Date or java.util.Calendar for date/time values. Because of this, it's impossible to use Java 8 date/time types with any of the i18n and localization tools.
>>> 
>>> MessageFormat really needs support for types in java.time. Should I file a bug somewhere about this (where?), or is this message enough to get this going? I'm not even sure how it should work. I'm not sure how MessageFormat can know whether a SimpleDateFormat string or a DateTimeFormatter string is being supplied. Possibly, validation of the format string must be delayed until either a Date/Calendar or a java.time type is supplied for formatting.
>> 
>> Looks like there _also_ needs to be java.time support in JAXB. I have a POJO with an @XmlElement "lastModified" of type java.time.Instant, and it just gets printed out  (the value is ignored). It should be printed out ISO 8601-formatted.



From paul.sandoz at oracle.com  Mon Jun 17 10:09:50 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 17 Jun 2013 12:09:50 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
Message-ID: 

On Jun 14, 2013, at 11:57 PM, Mike Duigou  wrote:
> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
> 

There are some places where the indentation looks wonky e.g. HashMap & LinkedHashMap changes.

The LinkedHashMap.forEach/replaceAll methods are checking modCount and throwing CME before the action is called.

The WeakHashMap.replaceAll method is checking the modCount per bucket, not-per element.

Are there existing tests for the overriding methods?

Otherwise looks OK.

Paul.


> For interference detection the strategy I am advocating is :
> 
> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.
> 
> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.
> 
> Mike
> 
> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
> 
>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>> 
>> Revised webrev:
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>> 
>> Mike
>> 
>> 
>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>> 
>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>> Hello all;
>>>> 
>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>> 
>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>> 
>>>> Mike
>>> 
>>> Hi Mike,
>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>> 
>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>> so you can not do a modCount check only at the end.
>>> 
>>> R?mi
>>> 
>>> Here is the diff.
>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -28,6 +28,7 @@
>>> import java.io.*;
>>> import java.lang.reflect.ParameterizedType;
>>> import java.lang.reflect.Type;
>>> +import java.util.function.BiConsumer;
>>> import java.util.function.Consumer;
>>> import java.util.function.BiFunction;
>>> import java.util.function.Function;
>>> @@ -2615,6 +2616,54 @@
>>>   int   capacity()     { return table.length; }
>>>   float loadFactor()   { return loadFactor;   }
>>> 
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        final int expectedModCount = modCount;
>>> +        if (nullKeyEntry != null) {
>>> +            forEachNullKey(expectedModCount, action);
>>> +        }
>>> +        Object[] table = this.table;
>>> +        for(int index = 0; index < table.length; index++) {
>>> +            Object item = table[index];
>>> +            if (item == null) {
>>> +                continue;
>>> +            }
>>> +            if (item instanceof HashMap.TreeBin) {
>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>> +                continue;
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)item;
>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>> +                if (expectedModCount != modCount) {
>>> +                    throw new ConcurrentModificationException();
>>> +                }
>>> +                action.accept(entry.key, entry.value);
>>> +            }
>>> +        }
>>> +    }
>>> +
>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>> +        while (node != null) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            @SuppressWarnings("unchecked")
>>> +            Entry entry = (Entry)node.entry;
>>> +            action.accept(entry.key, entry.value);
>>> +            node = (TreeNode)entry.next;
>>> +        }
>>> +    }
>>> +
>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>> +        if (expectedModCount != modCount) {
>>> +            throw new ConcurrentModificationException();
>>> +        }
>>> +        action.accept(null, nullKeyEntry.value);
>>> +    }
>>> +
>>>   /**
>>>    * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>    */
>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>> @@ -24,7 +24,8 @@
>>> */
>>> 
>>> package java.util;
>>> -import java.io.*;
>>> +
>>> +import java.util.function.BiConsumer;
>>> 
>>> /**
>>> * 
    Hash table and linked list implementation of the Map interface,
>>> @@ -470,4 +471,16 @@
>>>   protected boolean removeEldestEntry(Map.Entry eldest) {
>>>       return false;
>>>   }
>>> +
>>> +    @Override
>>> +    public void forEach(BiConsumer action) {
>>> +        Objects.requireNonNull(action);
>>> +        int expectedModCount = modCount;
>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>> +            if (expectedModCount != modCount) {
>>> +                throw new ConcurrentModificationException();
>>> +            }
>>> +            action.accept(entry.key, entry.value);
>>> +        }
>>> +    }
>>> }
>>> 
>>> 
>> 
> 



From peter.levart at gmail.com  Mon Jun 17 10:20:10 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 17 Jun 2013 12:20:10 +0200
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BEC37A.2010303@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
Message-ID: <51BEE2DA.2080301@gmail.com>

On 06/17/2013 10:06 AM, Aleksey Shipilev wrote:
> On 06/16/2013 11:44 PM, Alan Bateman wrote:
>> On 13/06/2013 12:47, Aleksey Shipilev wrote:
>>> Friendly reminder for the reviewers.
>>>
>>> On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
>>>> This is the follow-up on the issue Doug identified:
>>>>    
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
>>>>
>>>>
>>>> I had reworked the patch, webrev is here:
>>>>     http://cr.openjdk.java.net/~shade/8016236/webrev.01/
>>> The current webrev is here:
>>>     http://cr.openjdk.java.net/~shade/8016236/webrev.02/
>>>
>> I'm just catching up on this thread, webrev.02 looks very good to me. I
>> can sponsor it.
> Thanks! I'll appreciate this.
>
>> One comment on ClassRepositoryHolder is that it's "yet another class"
>> (we have a proliferation of holder classes since we started using this
>> idiom). It makes me wonder if it might be better to move the constant to
>> ClassRepository.
> Ok, makes sense. I moved it to ClassRepository itself. Given we have the
> ClassRepository field in Class, the static initialization will be
> performed on the first class load. I have no problems having it public,
> since it is protected enough from the external modifications.

Sorry, Aleksey, just a nit: In getInterfaces(), the method could be 
written using a single volatile read from ReflectionData.interfaces 
field instead of two (by introducing local variable).

Regards, Peter

>
> The new webrev is here:
>    http://cr.openjdk.java.net/~shade/8016236/webrev.03/
>
> Testing:
>    - Linux/x86_64/release build OK
>    - Linux/x86_64/release passes java/lang/reflect jtreg
>    - microbenchmark scores are still intact
>
> -Aleksey.



From chris.hegarty at oracle.com  Mon Jun 17 10:42:11 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 11:42:11 +0100
Subject: RFR (jaxp): 8016133 : Regression: diff. behavior with user-defined
	SAXParser
In-Reply-To: <51BEC61B.4090709@oracle.com>
References: <51B69B3D.1070707@oracle.com> <51BEC61B.4090709@oracle.com>
Message-ID: <51BEE803.10906@oracle.com>

Looks ok to me too Joe.

-Chris.

On 17/06/2013 09:17, Daniel Fuchs wrote:
> Hi Joe,
>
> Looks good to me. Not a reviewer - as you know ;-)
>
> -- daniel
>
> On 6/11/13 5:36 AM, huizhe wang wrote:
>> Hi,
>>
>> This is a quick fix on a regression caused by a previous patch. The
>> XMLReaderFactory uses a class variable (_jarread) to indicate if service
>> file has already been read. Along with this variable, there was another
>> (clsFromJar ) that caches the classname if found in a service file. The
>> 2nd variable and its use were accidentally removed. As a result, the
>> following code would return the 3rd party impl on first call but then
>> fall back to the default impl on subsequent calls because reading
>> service file was skipped when _jarread is true:
>> XMLReader reader = XMLReaderFactory.createXMLReader();
>> System.out.println("1:" + reader.getClass().getName());
>>
>> XMLReader reader2 = XMLReaderFactory.createXMLReader();
>> System.out.println("2:" + reader2.getClass().getName());
>>
>> The fix is simply recover the original code. Here's the webrev:
>>
>> http://cr.openjdk.java.net/~joehw/jdk8/8016133/webrev/
>>
>> Thanks,
>> Joe
>


From paul.sandoz at oracle.com  Mon Jun 17 11:23:17 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 17 Jun 2013 13:23:17 +0200
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended on
	TLR fields
In-Reply-To: <51BED035.30300@oracle.com>
References: <51BED035.30300@oracle.com>
Message-ID: <0A4AC980-D30B-4171-B7C2-FF84DE8C8F18@oracle.com>


On Jun 17, 2013, at 11:00 AM, Aleksey Shipilev  wrote:

> Hi,
> 
> This is the respin of the RFE filed a month ago:
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
> 
> The webrev is here:
>  http://cr.openjdk.java.net/~shade/8014233/webrev.02/
> 

Looks OK to me (with my lack of reviewing mojo).

More out of curiosity: how does this impact the memory-per-Thread with @Contended on fields rather than on the class?

Paul.

From Alan.Bateman at oracle.com  Mon Jun 17 11:40:54 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jun 2013 12:40:54 +0100
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: <9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net>
References: 
	<6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
	
	<9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net>
Message-ID: <51BEF5C6.9080304@oracle.com>

On 17/06/2013 11:05, Nick Williams wrote:
> Thanks. I have filed two different bugs for these two different problems.
Here they are:

8016743: java.text.MessageFormat does not support java.time.* types
8016742: JAXB does not support java.time.* types

Note that JAXB is maintained in an upstream project (they periodically 
do source drops into OpenJDK). I don't know if support for java.time 
requires API changes or not but just to mention that JAXB is tied to a 
standalone JSR and I think they the requirement to be able to drop-in 
into jdk7 builds.

-Alan


From Alan.Bateman at oracle.com  Mon Jun 17 11:44:49 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jun 2013 12:44:49 +0100
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BEC37A.2010303@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
Message-ID: <51BEF6B1.4050104@oracle.com>

On 17/06/2013 09:06, Aleksey Shipilev wrote:
> :
> Ok, makes sense. I moved it to ClassRepository itself. Given we have the
> ClassRepository field in Class, the static initialization will be
> performed on the first class load. I have no problems having it public,
> since it is protected enough from the external modifications.
>
> The new webrev is here:
>    http://cr.openjdk.java.net/~shade/8016236/webrev.03/
>
>
This looks to good. I agree with Peter's point about the 2 reads in 
getInterfaces() although it's unlikely to make a significant difference.

If you can create the change-set then I can push this for you today.

-Alan




From scolebourne at joda.org  Mon Jun 17 11:53:24 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 17 Jun 2013 12:53:24 +0100
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: <51BEF5C6.9080304@oracle.com>
References: 
	<6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
	
	<9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net>
	<51BEF5C6.9080304@oracle.com>
Message-ID: 

On 17 June 2013 12:40, Alan Bateman  wrote:
> On 17/06/2013 11:05, Nick Williams wrote:
>>
>> Thanks. I have filed two different bugs for these two different problems.
>
> Here they are:
>
> 8016743: java.text.MessageFormat does not support java.time.* types
> 8016742: JAXB does not support java.time.* types
>
> Note that JAXB is maintained in an upstream project (they periodically do
> source drops into OpenJDK). I don't know if support for java.time requires
> API changes or not but just to mention that JAXB is tied to a standalone JSR
> and I think they the requirement to be able to drop-in into jdk7 builds.

That could be a problem, but its really a process one. It shouldn't be
users that suffer as a result of issues like that (but there isn't
anything I can do about it other than wave my hands...)
Stephen


From Alan.Bateman at oracle.com  Mon Jun 17 11:56:57 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jun 2013 12:56:57 +0100
Subject: Cleanup of some doclint warnings in java.lang
In-Reply-To: <51BE86F2.8060104@oracle.com>
References: <51BE86F2.8060104@oracle.com>
Message-ID: <51BEF989.1060301@oracle.com>

On 17/06/2013 04:48, Joe Darcy wrote:
> Hello,
>
> Please review the patch below which resolves a subset of the doclint 
> warnings in java.lang.
>
> Thanks,
>
> -Joe
One comment on Double is that you've removed the  to fix the 
nesting issue. Did you consider replacing this with 
    {@code ... 
}
     so that you've got {@code ..} around the code fragment. That 
would avoid needing to check it for escaping.

Otherwise looks fine to me.

-Alan.


From aleksey.shipilev at oracle.com  Mon Jun 17 12:09:05 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 16:09:05 +0400
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <0A4AC980-D30B-4171-B7C2-FF84DE8C8F18@oracle.com>
References: <51BED035.30300@oracle.com>
	<0A4AC980-D30B-4171-B7C2-FF84DE8C8F18@oracle.com>
Message-ID: <51BEFC61.1080507@oracle.com>

On 06/17/2013 03:23 PM, Paul Sandoz wrote:
> Looks OK to me (with my lack of reviewing mojo).

Good, thanks.

> More out of curiosity: how does this impact the memory-per-Thread
> with @Contended on fields rather than on the class?

No difference at all. Class-level @Contended will have the padding
before and after the instance fields block, and @Contended("tlr") over
the fields will have the padding before and after those three fields
block. So, all-and-all, it is the same cost to pay.

-Aleksey.


From aleksey.shipilev at oracle.com  Mon Jun 17 12:13:49 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 16:13:49 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BEE2DA.2080301@gmail.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEE2DA.2080301@gmail.com>
Message-ID: <51BEFD7D.2050500@oracle.com>

On 06/17/2013 02:20 PM, Peter Levart wrote:
> Sorry, Aleksey, just a nit: In getInterfaces(), the method could be
> written using a single volatile read from ReflectionData.interfaces
> field instead of two (by introducing local variable).

Yes, thanks! Nothing to be sorry of, I'll cover this.

-Aleksey.



From aleksey.shipilev at oracle.com  Mon Jun 17 12:32:46 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 16:32:46 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BEF6B1.4050104@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEF6B1.4050104@oracle.com>
Message-ID: <51BF01EE.9060309@oracle.com>

On 06/17/2013 03:44 PM, Alan Bateman wrote:
> This looks to good. I agree with Peter's point about the 2 reads in 
> getInterfaces() although it's unlikely to make a significant
> difference.

Oh, it can have the difference on non-x86 hardware and/or in optimized
code. This nit is fixed here:
  http://cr.openjdk.java.net/~shade/8016236/webrev.04/

I did the same testing as before: Linux x86_64/release builds and runs
jdk/test/java/lang/reflect jtreg successfully; the performance is still
there.

> If you can create the change-set then I can push this for you today.

Here:
  http://cr.openjdk.java.net/~shade/8016236/8016236.changeset

Although only Alan counts as official reviewer; do we need another one?

Thanks,
-Aleksey.


From chris.hegarty at oracle.com  Mon Jun 17 12:43:42 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 13:43:42 +0100
Subject: Cleanup of some doclint warnings in java.lang
In-Reply-To: <51BE86F2.8060104@oracle.com>
References: <51BE86F2.8060104@oracle.com>
Message-ID: <51BF047E.9090000@oracle.com>

Looks fine to me Joe,

Quite trivially, and optionally, the '@since 1.8 ' could be moved to 
after the @return in Short.java L406

-Chris.

On 17/06/2013 04:48, Joe Darcy wrote:
> Hello,
>
> Please review the patch below which resolves a subset of the doclint
> warnings in java.lang.
>
> Thanks,
>
> -Joe
>
> diff -r 45a3584bfacf src/share/classes/java/lang/Boolean.java
> --- a/src/share/classes/java/lang/Boolean.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/Boolean.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1994, 2011, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -205,9 +205,9 @@
> * Returns a hash code for a {@code boolean} value; compatible with
> * {@code Boolean.hashCode()}.
> *
> + * @param value the value to hash
> + * @return a hash code value for a {@code boolean} value.
> * @since 1.8
> - *
> - * @return a hash code value for a {@code boolean} value.
> */
> public static int hashCode(boolean value) {
> return value ? 1231 : 1237;
> diff -r 45a3584bfacf src/share/classes/java/lang/Byte.java
> --- a/src/share/classes/java/lang/Byte.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Byte.java Sun Jun 16 20:46:52 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -398,9 +398,9 @@
> * Returns a hash code for a {@code byte} value; compatible with
> * {@code Byte.hashCode()}.
> *
> + * @param value the value to hash
> + * @return a hash code value for a {@code byte} value.
> * @since 1.8
> - *
> - * @return a hash code value for a {@code byte} value.
> */
> public static int hashCode(byte value) {
> return (int)value;
> diff -r 45a3584bfacf src/share/classes/java/lang/Class.java
> --- a/src/share/classes/java/lang/Class.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Class.java Sun Jun 16 20:46:52 2013 -0700
> @@ -3141,6 +3141,8 @@
> * could not be checked at runtime (because generic types are implemented
> * by erasure).
> *
> + * @param  the type to cast this class object to
> + * @param clazz the class of the type to cast this class object to
> * @return this {@code Class} object, cast to represent a subclass of
> * the specified class object.
> * @throws ClassCastException if this {@code Class} object does not
> @@ -3296,6 +3298,7 @@
> * If this Class represents either the Object class, an interface type, an
> * array type, a primitive type, or void, the return value is null.
> *
> + * @return an object representing the superclass
> * @since 1.8
> */
> public AnnotatedType getAnnotatedSuperclass() {
> @@ -3327,6 +3330,7 @@
> * If this Class represents either the Object class, an array type, a
> * primitive type, or void, the return value is an array of length 0.
> *
> + * @return an array representing the superinterfaces
> * @since 1.8
> */
> public AnnotatedType[] getAnnotatedInterfaces() {
> diff -r 45a3584bfacf src/share/classes/java/lang/Double.java
> --- a/src/share/classes/java/lang/Double.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/Double.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -453,7 +453,6 @@
> * a {@code NumberFormatException} be thrown, the regular
> * expression below can be used to screen the input string:
> *
> - * 
> * 
    > * final String Digits = "(\\p{Digit}+)";
> * final String HexDigits = "(\\p{XDigit}+)";
> @@ -500,7 +499,6 @@
> * // Perform suitable alternative action
> * }
> * 
    
> - *     
> *
> * @param s the string to be parsed.
> * @return a {@code Double} object holding the value
> @@ -756,9 +754,9 @@
> * Returns a hash code for a {@code double} value; compatible with
> * {@code Double.hashCode()}.
> *
> + * @param value the value to hash
> + * @return a hash code value for a {@code double} value.
> * @since 1.8
> - *
> - * @return a hash code value for a {@code double} value.
> */
> public static int hashCode(double value) {
> long bits = doubleToLongBits(value);
> diff -r 45a3584bfacf src/share/classes/java/lang/Float.java
> --- a/src/share/classes/java/lang/Float.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Float.java Sun Jun 16 20:46:52 2013 -0700
> @@ -664,9 +664,9 @@
> * Returns a hash code for a {@code float} value; compatible with
> * {@code Float.hashCode()}.
> *
> + * @param value the value to hash
> + * @return a hash code value for a {@code float} value.
> * @since 1.8
> - *
> - * @return a hash code value for a {@code float} value.
> */
> public static int hashCode(float value) {
> return floatToIntBits(value);
> diff -r 45a3584bfacf src/share/classes/java/lang/Integer.java
> --- a/src/share/classes/java/lang/Integer.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/Integer.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -947,6 +947,7 @@
> * Returns a hash code for a {@code int} value; compatible with
> * {@code Integer.hashCode()}.
> *
> + * @param value the value to hash
> * @since 1.8
> *
> * @return a hash code value for a {@code int} value.
> @@ -1332,6 +1333,7 @@
> * one-bits in its two's complement binary representation, that is, if it
> * is equal to zero.
> *
> + * @param i the value whose highest one bit is to be computed
> * @return an {@code int} value with a single one-bit, in the position
> * of the highest-order one-bit in the specified value, or zero if
> * the specified value is itself equal to zero.
> @@ -1354,6 +1356,7 @@
> * one-bits in its two's complement binary representation, that is, if it
> * is equal to zero.
> *
> + * @param i the value whose lowest one bit is to be computed
> * @return an {@code int} value with a single one-bit, in the position
> * of the lowest-order one-bit in the specified value, or zero if
> * the specified value is itself equal to zero.
> @@ -1378,6 +1381,7 @@
> * 
  • ceil(log2(x)) = {@code 32 - numberOfLeadingZeros(x - 1)}
> * 
> *
> + * @param i the value whose number of leading zeros is to be computed
> * @return the number of zero bits preceding the highest-order
> * ("leftmost") one-bit in the two's complement binary representation
> * of the specified {@code int} value, or 32 if the value
> @@ -1404,6 +1408,7 @@
> * one-bits in its two's complement representation, in other words if it is
> * equal to zero.
> *
> + * @param i the value whose number of trailing zeros is to be computed
> * @return the number of zero bits following the lowest-order ("rightmost")
> * one-bit in the two's complement binary representation of the
> * specified {@code int} value, or 32 if the value is equal
> @@ -1427,6 +1432,7 @@
> * representation of the specified {@code int} value. This function is
> * sometimes referred to as the population count.
> *
> + * @param i the value whose bits are to be counted
> * @return the number of one-bits in the two's complement binary
> * representation of the specified {@code int} value.
> * @since 1.5
> @@ -1454,6 +1460,8 @@
> * ignored, even if the distance is negative: {@code rotateLeft(val,
> * distance) == rotateLeft(val, distance & 0x1F)}.
> *
> + * @param i the value whose bits are to be rotated left
> + * @param distance the number of bit positions to rotate left
> * @return the value obtained by rotating the two's complement binary
> * representation of the specified {@code int} value left by the
> * specified number of bits.
> @@ -1476,6 +1484,8 @@
> * ignored, even if the distance is negative: {@code rotateRight(val,
> * distance) == rotateRight(val, distance & 0x1F)}.
> *
> + * @param i the value whose bits are to be rotated right
> + * @param distance the number of bit positions to rotate right
> * @return the value obtained by rotating the two's complement binary
> * representation of the specified {@code int} value right by the
> * specified number of bits.
> @@ -1490,6 +1500,7 @@
> * two's complement binary representation of the specified {@code int}
> * value.
> *
> + * @param i the value to be reversed
> * @return the value obtained by reversing order of the bits in the
> * specified {@code int} value.
> * @since 1.5
> @@ -1509,6 +1520,7 @@
> * return value is -1 if the specified value is negative; 0 if the
> * specified value is zero; and 1 if the specified value is positive.)
> *
> + * @param i the value whose signum is to be computed
> * @return the signum function of the specified {@code int} value.
> * @since 1.5
> */
> @@ -1521,6 +1533,7 @@
> * Returns the value obtained by reversing the order of the bytes in the
> * two's complement representation of the specified {@code int} value.
> *
> + * @param i the value whose bytes are to be reversed
> * @return the value obtained by reversing the bytes in the specified
> * {@code int} value.
> * @since 1.5
> diff -r 45a3584bfacf src/share/classes/java/lang/Long.java
> --- a/src/share/classes/java/lang/Long.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Long.java Sun Jun 16 20:46:52 2013 -0700
> @@ -1053,9 +1053,9 @@
> * Returns a hash code for a {@code long} value; compatible with
> * {@code Long.hashCode()}.
> *
> + * @param value the value to hash
> + * @return a hash code value for a {@code long} value.
> * @since 1.8
> - *
> - * @return a hash code value for a {@code long} value.
> */
> public static int hashCode(long value) {
> return (int)(value ^ (value >>> 32));
> @@ -1357,6 +1357,7 @@
> * one-bits in its two's complement binary representation, that is, if it
> * is equal to zero.
> *
> + * @param i the value whose highest one bit is to be computed
> * @return a {@code long} value with a single one-bit, in the position
> * of the highest-order one-bit in the specified value, or zero if
> * the specified value is itself equal to zero.
> @@ -1380,6 +1381,7 @@
> * one-bits in its two's complement binary representation, that is, if it
> * is equal to zero.
> *
> + * @param i the value whose lowest one bit is to be computed
> * @return a {@code long} value with a single one-bit, in the position
> * of the lowest-order one-bit in the specified value, or zero if
> * the specified value is itself equal to zero.
> @@ -1404,6 +1406,7 @@
> * 
  • ceil(log2(x)) = {@code 64 - numberOfLeadingZeros(x - 1)}
> * 
> *
> + * @param i the value whose number of leading zeros is to be computed
> * @return the number of zero bits preceding the highest-order
> * ("leftmost") one-bit in the two's complement binary representation
> * of the specified {@code long} value, or 64 if the value
> @@ -1432,6 +1435,7 @@
> * one-bits in its two's complement representation, in other words if it is
> * equal to zero.
> *
> + * @param i the value whose number of trailing zeros is to be computed
> * @return the number of zero bits following the lowest-order ("rightmost")
> * one-bit in the two's complement binary representation of the
> * specified {@code long} value, or 64 if the value is equal
> @@ -1456,6 +1460,7 @@
> * representation of the specified {@code long} value. This function is
> * sometimes referred to as the population count.
> *
> + * @param i the value whose bits are to be counted
> * @return the number of one-bits in the two's complement binary
> * representation of the specified {@code long} value.
> * @since 1.5
> @@ -1484,6 +1489,8 @@
> * ignored, even if the distance is negative: {@code rotateLeft(val,
> * distance) == rotateLeft(val, distance & 0x3F)}.
> *
> + * @param i the value whose bits are to be rotated left
> + * @param distance the number of bit positions to rotate left
> * @return the value obtained by rotating the two's complement binary
> * representation of the specified {@code long} value left by the
> * specified number of bits.
> @@ -1506,6 +1513,8 @@
> * ignored, even if the distance is negative: {@code rotateRight(val,
> * distance) == rotateRight(val, distance & 0x3F)}.
> *
> + * @param i the value whose bits are to be rotated right
> + * @param distance the number of bit positions to rotate right
> * @return the value obtained by rotating the two's complement binary
> * representation of the specified {@code long} value right by the
> * specified number of bits.
> @@ -1520,6 +1529,7 @@
> * two's complement binary representation of the specified {@code long}
> * value.
> *
> + * @param i the value to be reversed
> * @return the value obtained by reversing order of the bits in the
> * specified {@code long} value.
> * @since 1.5
> @@ -1540,6 +1550,7 @@
> * return value is -1 if the specified value is negative; 0 if the
> * specified value is zero; and 1 if the specified value is positive.)
> *
> + * @param i the value whose signum is to be computed
> * @return the signum function of the specified {@code long} value.
> * @since 1.5
> */
> @@ -1552,6 +1563,7 @@
> * Returns the value obtained by reversing the order of the bytes in the
> * two's complement representation of the specified {@code long} value.
> *
> + * @param i the value whose bytes are to be reversed
> * @return the value obtained by reversing the bytes in the specified
> * {@code long} value.
> * @since 1.5
> diff -r 45a3584bfacf src/share/classes/java/lang/Math.java
> --- a/src/share/classes/java/lang/Math.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Math.java Sun Jun 16 20:46:52 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1994, 2012, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1994, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> diff -r 45a3584bfacf src/share/classes/java/lang/Package.java
> --- a/src/share/classes/java/lang/Package.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/Package.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -77,18 +77,18 @@
> * by the following formal grammar:
> * 
    
> * 
    
> - * 
    SpecificationVersion:
> - * 
    Digits RefinedVersionopt
> + * 
    SpecificationVersion:
> + * 
    Digits RefinedVersionopt
>
> - * 
    RefinedVersion:
> + * 
    RefinedVersion:
> * 
    {@code .} Digits
> * 
    {@code .} Digits RefinedVersion
> *
> - * 
    Digits:
> - * 
    Digit
> - * 
    Digits
> + * 
    Digits:
> + * 
    Digit
> + * 
    Digits
> *
> - * 
    Digit:
> + * 
    Digit:
> * 
    any character for which {@link Character#isDigit} returns {@code
> true},
> * e.g. 0, 1, 2, ...
> * 
    
> diff -r 45a3584bfacf src/share/classes/java/lang/Runtime.java
> --- a/src/share/classes/java/lang/Runtime.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/Runtime.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -117,11 +117,11 @@
> *
> * 
      
> *
> - * 
       
    •  The program exits normally, when the last non-daemon
> + * 
    •  The program exits normally, when the last non-daemon
> * thread exits or when the {@link #exit exit} (equivalently,
> - * {@link System#exit(int) System.exit}) method is invoked, or
> + * {{@link System#exit(int) System.exit}) method is invoked, or
> *
> - * 
       
    •  The virtual machine is terminated in response to a
> + * 
    •  The virtual machine is terminated in response to a
> * user interrupt, such as typing ^C, or a system-wide event,
> * such as user logoff or system shutdown.
> *
> diff -r 45a3584bfacf src/share/classes/java/lang/Short.java
> --- a/src/share/classes/java/lang/Short.java Fri Jun 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/Short.java Sun Jun 16 20:46:52 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -405,6 +405,7 @@
> *
> * @since 1.8
> *
> + * @param value the value to hash
> * @return a hash code value for a {@code short} value.
> */
> public static int hashCode(short value) {
> @@ -482,6 +483,7 @@
> * Returns the value obtained by reversing the order of the bytes in the
> * two's complement representation of the specified {@code short} value.
> *
> + * @param i the value whose bytes are to be reversed
> * @return the value obtained by reversing (or, equivalently, swapping)
> * the bytes in the specified {@code short} value.
> * @since 1.5
> diff -r 45a3584bfacf src/share/classes/java/lang/StrictMath.java
> --- a/src/share/classes/java/lang/StrictMath.java Fri Jun 14 15:14:56
> 2013 +0400
> +++ b/src/share/classes/java/lang/StrictMath.java Sun Jun 16 20:46:52
> 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2012, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -1419,6 +1419,7 @@
> * {@link Float#MIN_EXPONENT} -1.
> * 
    
> * @param f a {@code float} value
> + * @return the unbiased exponent of the argument
> * @since 1.6
> */
> public static int getExponent(float f) {
> @@ -1436,6 +1437,7 @@
> * {@link Double#MIN_EXPONENT} -1.
> * 
> * @param d a {@code double} value
> + * @return the unbiased exponent of the argument
> * @since 1.6
> */
> public static int getExponent(double d) {
> diff -r 45a3584bfacf src/share/classes/java/lang/SuppressWarnings.java
> --- a/src/share/classes/java/lang/SuppressWarnings.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/SuppressWarnings.java Sun Jun 16
> 20:46:52 2013 -0700
> @@ -66,6 +66,7 @@
> * additional warning names they support in conjunction with this
> * annotation type. They are encouraged to cooperate to ensure
> * that the same names work across multiple compilers.
> + * @return the set of warnings to be suppressed
> */
> String[] value();
> }
> diff -r 45a3584bfacf src/share/classes/java/lang/System.java
> --- a/src/share/classes/java/lang/System.java Fri Jun 14 15:14:56 2013
> +0400
> +++ b/src/share/classes/java/lang/System.java Sun Jun 16 20:46:52 2013
> -0700
> @@ -634,6 +634,8 @@
> *
> * 
    On UNIX systems, it returns {@code "\n"}; on Microsoft
> * Windows systems it returns {@code "\r\n"}.
> + *
> + * @return the system-dependent line separator string
> * @since 1.7
> */
> public static String lineSeparator() {
> diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Annotation.java
> --- a/src/share/classes/java/lang/annotation/Annotation.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/annotation/Annotation.java Sun Jun 16
> 20:46:52 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -126,6 +126,7 @@
>
> /**
> * Returns the annotation type of this annotation.
> + * @return the annotation type of this annotation
> */
> Class annotationType();
>


From chris.hegarty at oracle.com  Mon Jun 17 12:48:27 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 13:48:27 +0100
Subject: Cleanup of doclint warnings in java.lang.{annotation, reflect}
In-Reply-To: <51BE4B89.3080102@oracle.com>
References: <51BE4B89.3080102@oracle.com>
Message-ID: <51BF059B.9010408@oracle.com>

Looks ok to me.

-Chris.

On 17/06/2013 00:34, Joe Darcy wrote:
> Hello,
>
> Please review the diff below of changes to get java.lang.annotation and
> java.lang.reflect clean on doclint warnings.
>
> I soon plan to send out another patch to cleanup java.lang; I'll file
> one or more bugs to cover this work depending on how reviews come in.
>
> Thanks,
>
> -Joe
>
> diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Annotation.java
> --- a/src/share/classes/java/lang/annotation/Annotation.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/annotation/Annotation.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -126,6 +126,7 @@
>
> /**
> * Returns the annotation type of this annotation.
> + * @return the annotation type of this annotation
> */
> Class annotationType();
> }
> diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Repeatable.java
> --- a/src/share/classes/java/lang/annotation/Repeatable.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/annotation/Repeatable.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -43,6 +43,7 @@
> /**
> * Indicates the containing annotation type for the
> * repeatable annotation type.
> + * @return the containing annotation type
> */
> Class value();
> }
> diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Retention.java
> --- a/src/share/classes/java/lang/annotation/Retention.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/annotation/Retention.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -44,5 +44,9 @@
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.ANNOTATION_TYPE)
> public @interface Retention {
> + /**
> + * Returns the retention policy.
> + * @return the retention policy
> + */
> RetentionPolicy value();
> }
> diff -r 45a3584bfacf src/share/classes/java/lang/annotation/Target.java
> --- a/src/share/classes/java/lang/annotation/Target.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/annotation/Target.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -67,5 +67,11 @@
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.ANNOTATION_TYPE)
> public @interface Target {
> + /**
> + * Returns an array of the kinds of elements an annotation type
> + * can be applied to.
> + * @return an array of the kinds of elements an annotation type
> + * can be applied to
> + */
> ElementType[] value();
> }
> diff -r 45a3584bfacf
> src/share/classes/java/lang/reflect/AnnotatedElement.java
> --- a/src/share/classes/java/lang/reflect/AnnotatedElement.java Fri Jun
> 14 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/reflect/AnnotatedElement.java Sun Jun
> 16 16:34:09 2013 -0700
> @@ -130,6 +130,7 @@
> * Returns this element's annotation for the specified type if
> * such an annotation is present, else null.
> *
> + * @param  the type of the annotation to query for and return if
> present
> * @param annotationClass the Class object corresponding to the
> * annotation type
> * @return this element's annotation for the specified annotation type if
> @@ -154,6 +155,7 @@
> * The caller of this method is free to modify the returned array; it will
> * have no effect on the arrays returned to other callers.
> *
> + * @param  the type of the annotation to query for and return if
> present
> * @param annotationClass the Class object corresponding to the
> * annotation type
> * @return all this element's annotations for the specified annotation
> type if
> @@ -184,6 +186,7 @@
> * This method ignores inherited annotations. (Returns null if no
> * annotations are directly present on this element.)
> *
> + * @param  the type of the annotation to query for and return if
> present
> * @param annotationClass the Class object corresponding to the
> * annotation type
> * @return this element's annotation for the specified annotation type if
> @@ -209,6 +212,8 @@
> * The caller of this method is free to modify the returned array; it will
> * have no effect on the arrays returned to other callers.
> *
> + * @param  the type of the annotation to query for and return
> + * if directly present
> * @param annotationClass the Class object corresponding to the
> * annotation type
> * @return all this element's annotations for the specified annotation
> type if
> diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Executable.java
> --- a/src/share/classes/java/lang/reflect/Executable.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/reflect/Executable.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -384,6 +384,8 @@
> /**
> * Returns a string describing this {@code Executable}, including
> * any type parameters.
> + * @return a string describing this {@code Executable}, including
> + * any type parameters
> */
> public abstract String toGenericString();
>
> @@ -496,6 +498,8 @@
> * If this Executable represents a method, the AnnotatedType object
> * represents the use of a type to specify the return type of the method.
> *
> + * @return an object representing the return type of this method
> + * or constructor
> * @since 1.8
> */
> public abstract AnnotatedType getAnnotatedReturnType();
> @@ -531,6 +535,9 @@
> *
> * Returns null if this Executable represents a static method.
> *
> + * @return an object representing the receiver type of the
> + * method or constructor represented by this Executable
> + *
> * @since 1.8
> */
> public AnnotatedType getAnnotatedReceiverType() {
> @@ -553,6 +560,9 @@
> * Returns an array of length 0 if the method/constructor declares no
> * parameters.
> *
> + * @return an array of objects representing the types of the
> + * formal parameters of this method or constructor
> + *
> * @since 1.8
> */
> public AnnotatedType[] getAnnotatedParameterTypes() {
> @@ -575,6 +585,9 @@
> * Returns an array of length 0 if the method/constructor declares no
> * exceptions.
> *
> + * @return an array of objects representing the declared
> + * exceptions of this method or constructor
> + *
> * @since 1.8
> */
> public AnnotatedType[] getAnnotatedExceptionTypes() {
> diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Field.java
> --- a/src/share/classes/java/lang/reflect/Field.java Fri Jun 14 15:14:56
> 2013 +0400
> +++ b/src/share/classes/java/lang/reflect/Field.java Sun Jun 16 16:34:09
> 2013 -0700
> @@ -1151,7 +1151,9 @@
> /**
> * Returns an AnnotatedType object that represents the use of a type to
> specify
> * the declared type of the field represented by this Field.
> - *
> + * @return an object representing the declared type of the field
> + * represented by this Field
> + *
> * @since 1.8
> */
> public AnnotatedType getAnnotatedType() {
> diff -r 45a3584bfacf src/share/classes/java/lang/reflect/Parameter.java
> --- a/src/share/classes/java/lang/reflect/Parameter.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/reflect/Parameter.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -152,6 +152,8 @@
> * defined in a class file, then that name will be returned by
> * this method. Otherwise, this method will synthesize a name of
> * the form argN, where N is the index of the parameter.
> + *
> + * @return the name of the parameter
> */
> public String getName() {
> // Note: empty strings as paramete names are now outlawed.
> diff -r 45a3584bfacf src/share/classes/java/lang/reflect/TypeVariable.java
> --- a/src/share/classes/java/lang/reflect/TypeVariable.java Fri Jun 14
> 15:14:56 2013 +0400
> +++ b/src/share/classes/java/lang/reflect/TypeVariable.java Sun Jun 16
> 16:34:09 2013 -0700
> @@ -95,6 +95,7 @@
> *
> * Returns an array of length 0 if the type parameter declares no bounds.
> *
> + * @return an array of objects representing the upper bounds of the
> type variable
> * @since 1.8
> */
> AnnotatedType[] getAnnotatedBounds();
>


From chris.hegarty at oracle.com  Mon Jun 17 12:52:04 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 13:52:04 +0100
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <51BED035.30300@oracle.com>
References: <51BED035.30300@oracle.com>
Message-ID: <51BF0674.3090801@oracle.com>

Looks fine to me Aleksey.

Let me know if you need a sponsor.

-Chris.

On 17/06/2013 10:00, Aleksey Shipilev wrote:
> Hi,
>
> This is the respin of the RFE filed a month ago:
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
>
> The webrev is here:
>    http://cr.openjdk.java.net/~shade/8014233/webrev.02/
>
> Testing:
>    - JPRT build passes
>    - Linux x86_64/release passes jdk/java/lang jtreg
>    - vm.quick.testlist, vm.quick-gc.testlist on selected platforms
>    - microbenchmarks, see below
>
> The rationale follows.
>
> After we merged ThreadLocalRandom state in the thread, we are now
> missing the padding to prevent false sharing on those heavily-updated
> fields. While the Thread is already large enough to separate two TLR
> states for two distinct threads, we can still get the false sharing with
> other thread fields.
>
> There is the benchmark showcasing this:
>    http://cr.openjdk.java.net/~shade/8014233/threadbench.zip
>
> There are two test cases: first one is only calling its own TLR with
> nextInt() and then the current thread's ID, another test calls *another*
> thread ID, thus inducing the false sharing against another thread's TLR
> state.
>
> On my 2x2 i5 laptop, running Linux x86_64:
>    same:    355 +- 1 ops/usec
>    other:   100 +- 5 ops/usec
>
> Note the decrease in throughput because of the false sharing.
>
> With the patch:
>    same:    359 +- 1 ops/usec
>    other:   356 +- 1 ops/usec
>
> Note the performance is back. We want to evade these spurious decreases
> in performance, due to either unlucky memory layout, or the user code
> (un)intentionally ruining the cache line locality for the updater thread.
>
> Thanks,
> -Aleksey.


From chris.hegarty at oracle.com  Mon Jun 17 13:11:42 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 17 Jun 2013 13:11:42 +0000
Subject: hg: jdk8/tl/jdk: 8016747: Replace deprecated PlatformLogger
	isLoggable(int) with isLoggable(Level)
Message-ID: <20130617131207.48AE448268@hg.openjdk.java.net>

Changeset: adf70cb48ce0
Author:    chegar
Date:      2013-06-17 14:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adf70cb48ce0

8016747: Replace deprecated PlatformLogger isLoggable(int) with isLoggable(Level)
Reviewed-by: darcy

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/AttributeValue.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Container.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/Cursor.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/SplashScreen.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/net/CookieManager.java
! src/share/classes/java/util/Currency.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/ScrollPaneWheelScroller.java
! src/share/classes/sun/awt/SunDisplayChanger.java
! src/share/classes/sun/awt/SunGraphicsCallback.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/font/SunFontManager.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/solaris/classes/sun/awt/X11/ListHelper.java
! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java
! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java
! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/solaris/classes/sun/awt/X11/XErrorHandlerUtil.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XMenuWindow.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/windows/classes/sun/awt/windows/WToolkit.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java



From nicholas+openjdk at nicholaswilliams.net  Mon Jun 17 13:17:44 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Mon, 17 Jun 2013 08:17:44 -0500
Subject: There needs to be support for java.time in java.text.MessageFormat
In-Reply-To: 
References: 
	<6E32374C-BB4B-4A38-8540-88F32B859A88@nicholaswilliams.net>
	
	<9DB44E16-FC4B-4D52-9B08-4DDCAB345916@nicholaswilliams.net>
	<51BEF5C6.9080304@oracle.com>
	
Message-ID: 


On Jun 17, 2013, at 6:53 AM, Stephen Colebourne wrote:

> On 17 June 2013 12:40, Alan Bateman  wrote:
>> On 17/06/2013 11:05, Nick Williams wrote:
>>> 
>>> Thanks. I have filed two different bugs for these two different problems.
>> 
>> Here they are:
>> 
>> 8016743: java.text.MessageFormat does not support java.time.* types
>> 8016742: JAXB does not support java.time.* types
>> 
>> Note that JAXB is maintained in an upstream project (they periodically do
>> source drops into OpenJDK). I don't know if support for java.time requires
>> API changes or not but just to mention that JAXB is tied to a standalone JSR
>> and I think they the requirement to be able to drop-in into jdk7 builds.
> 
> That could be a problem, but its really a process one. It shouldn't be
> users that suffer as a result of issues like that (but there isn't
> anything I can do about it other than wave my hands...)
> Stephen

^^ What Stephen said. :-)

From daniel.fuchs at oracle.com  Mon Jun 17 13:21:17 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Jun 2013 15:21:17 +0200
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
Message-ID: <51BF0D4D.8060608@oracle.com>

Hi,

Please find below a webrev for fixing
8014218: test/java/util/logging/DrainFindDeadlockTest.java failing 
intermittently



Without the fix - it's quite easy to make the test fail - especially
if you copy paste the @run line a few times.

This test is supposed to detect a deadlock in Logger initialization,
but it detects too many false positive.
An analysis of stack traces that the test dumps when it fails shows
that there is actually no deadlock, since one of the two supposed
deadlock threads is RUNNABLE.

However - this - I think - indicates a bug in
ThreadMXBean.findDeadlockedThreads().

I have rewritten the test to sanitize the results before
and after calling ThreadMXBean.findDeadlockedThreads().

Namely - the test will call ThreadMXBean.findDeadlockedThreads()
only if the two threads it monitors are simultaneously blocked
(obtained by examining ThreadMXBean.getThreadInfo(long[])), and
will verify that all threads found in deadlock by 
ThreadMXBean.findDeadlockedThreads() are indeed blocked.

Now - I'm not sure whether this is a good thing or not:

pros: it makes it possible to run this test again - and have a greater
       confidence that if it fails it's because of a genuine deadlock,
       which is desirable.

cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
       as it appears the test was testing
       ThreadMXBean.findDeadlockedThreads() more than (or as much
       as) it was testing the Logger implementation.

Does it make sense to push this fix and log a bug against ThreadMXBean?
Or should I instead plan to add this test to the problem list
(and re-qualify the bug as an issue in ThreadMXBean)?

guidance appreciated!

best regards,

-- daniel




From Alan.Bateman at oracle.com  Mon Jun 17 13:22:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Jun 2013 14:22:15 +0100
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BF01EE.9060309@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEF6B1.4050104@oracle.com> <51BF01EE.9060309@oracle.com>
Message-ID: <51BF0D87.7090702@oracle.com>

On 17/06/2013 13:32, Aleksey Shipilev wrote:
> On 06/17/2013 03:44 PM, Alan Bateman wrote:
>> This looks to good. I agree with Peter's point about the 2 reads in
>> getInterfaces() although it's unlikely to make a significant
>> difference.
> Oh, it can have the difference on non-x86 hardware and/or in optimized
> code. This nit is fixed here:
>    http://cr.openjdk.java.net/~shade/8016236/webrev.04/
>
> I did the same testing as before: Linux x86_64/release builds and runs
> jdk/test/java/lang/reflect jtreg successfully; the performance is still
> there.
>
>> If you can create the change-set then I can push this for you today.
> Here:
>    http://cr.openjdk.java.net/~shade/8016236/8016236.changeset
>
> Although only Alan counts as official reviewer; do we need another one?
>
The updated webrev looks good for me.

For the jdk repository then only one reviewer with "reviewer" role is 
required. I see you have Peter and Paul listed in a Reviewed-by line so 
I think we are good. Do you want Doug listed too as this started out as 
a patch from Doug.

-Alan


From aleksey.shipilev at oracle.com  Mon Jun 17 13:25:01 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 17:25:01 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BF0D87.7090702@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEF6B1.4050104@oracle.com> <51BF01EE.9060309@oracle.com>
	<51BF0D87.7090702@oracle.com>
Message-ID: <51BF0E2D.2070407@oracle.com>

On 06/17/2013 05:22 PM, Alan Bateman wrote:
> For the jdk repository then only one reviewer with "reviewer" role is
> required. I see you have Peter and Paul listed in a Reviewed-by line so
> I think we are good. Do you want Doug listed too as this started out as
> a patch from Doug.

Ouch! My bad. Doug had not reviewed the final patch, and the final patch
is significantly different from the original one. Do we still want to
put Doug to Contributed-by, or is there some other tag useful in cases
like these?

-Aleksey.



From aleksey.shipilev at oracle.com  Mon Jun 17 13:28:11 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 17:28:11 +0400
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <51BF0674.3090801@oracle.com>
References: <51BED035.30300@oracle.com> <51BF0674.3090801@oracle.com>
Message-ID: <51BF0EEB.809@oracle.com>

Thanks! I do need a sponsor.

-Aleksey.

On 06/17/2013 04:52 PM, Chris Hegarty wrote:
> Looks fine to me Aleksey.
> 
> Let me know if you need a sponsor.
> 
> -Chris.
> 
> On 17/06/2013 10:00, Aleksey Shipilev wrote:
>> Hi,
>>
>> This is the respin of the RFE filed a month ago:
>>   
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
>>
>> The webrev is here:
>>    http://cr.openjdk.java.net/~shade/8014233/webrev.02/
>>
>> Testing:
>>    - JPRT build passes
>>    - Linux x86_64/release passes jdk/java/lang jtreg
>>    - vm.quick.testlist, vm.quick-gc.testlist on selected platforms
>>    - microbenchmarks, see below
>>
>> The rationale follows.
>>
>> After we merged ThreadLocalRandom state in the thread, we are now
>> missing the padding to prevent false sharing on those heavily-updated
>> fields. While the Thread is already large enough to separate two TLR
>> states for two distinct threads, we can still get the false sharing with
>> other thread fields.
>>
>> There is the benchmark showcasing this:
>>    http://cr.openjdk.java.net/~shade/8014233/threadbench.zip
>>
>> There are two test cases: first one is only calling its own TLR with
>> nextInt() and then the current thread's ID, another test calls *another*
>> thread ID, thus inducing the false sharing against another thread's TLR
>> state.
>>
>> On my 2x2 i5 laptop, running Linux x86_64:
>>    same:    355 +- 1 ops/usec
>>    other:   100 +- 5 ops/usec
>>
>> Note the decrease in throughput because of the false sharing.
>>
>> With the patch:
>>    same:    359 +- 1 ops/usec
>>    other:   356 +- 1 ops/usec
>>
>> Note the performance is back. We want to evade these spurious decreases
>> in performance, due to either unlucky memory layout, or the user code
>> (un)intentionally ruining the cache line locality for the updater thread.
>>
>> Thanks,
>> -Aleksey.



From dl at cs.oswego.edu  Mon Jun 17 13:33:29 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 17 Jun 2013 09:33:29 -0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BF0E2D.2070407@oracle.com>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEF6B1.4050104@oracle.com> <51BF01EE.9060309@oracle.com>
	<51BF0D87.7090702@oracle.com> <51BF0E2D.2070407@oracle.com>
Message-ID: <51BF1029.5040306@cs.oswego.edu>

On 06/17/13 09:25, Aleksey Shipilev wrote:

> Ouch! My bad. Doug had not reviewed the final patch, and the final patch
> is significantly different from the original one. Do we still want to
> put Doug to Contributed-by, or is there some other tag useful in cases
> like these?
>

It looks fine to me. Thanks for the thorough care and testing.

I don't think we distinguish idea-cotributed-by vs code-contributed-by :-)

-Doug




From aleksey.shipilev at oracle.com  Mon Jun 17 13:38:05 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 17 Jun 2013 17:38:05 +0400
Subject: RFR (S) CR 8016236: Class.getGenericInterfaces performance
	improvement
In-Reply-To: <51BF1029.5040306@cs.oswego.edu>
References: <51B5F684.9010600@oracle.com> <51B9B157.10708@oracle.com>
	<51BE1591.8010901@oracle.com> <51BEC37A.2010303@oracle.com>
	<51BEF6B1.4050104@oracle.com> <51BF01EE.9060309@oracle.com>
	<51BF0D87.7090702@oracle.com> <51BF0E2D.2070407@oracle.com>
	<51BF1029.5040306@cs.oswego.edu>
Message-ID: <51BF113D.4060109@oracle.com>

On 06/17/2013 05:33 PM, Doug Lea wrote:
> On 06/17/13 09:25, Aleksey Shipilev wrote:
> 
>> Ouch! My bad. Doug had not reviewed the final patch, and the final patch
>> is significantly different from the original one. Do we still want to
>> put Doug to Contributed-by, or is there some other tag useful in cases
>> like these?
>>
> 
> It looks fine to me. Thanks for the thorough care and testing.
> 
> I don't think we distinguish idea-cotributed-by vs code-contributed-by :-)

Thanks!

I had updated the changeset capturing both:
  http://cr.openjdk.java.net/~shade/8016236/8016236.changeset

-Aleksey.



From chris.hegarty at oracle.com  Mon Jun 17 14:22:45 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 15:22:45 +0100
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
In-Reply-To: <51BF0D4D.8060608@oracle.com>
References: <51BF0D4D.8060608@oracle.com>
Message-ID: <51BF1BB5.9060901@oracle.com>

On 17/06/2013 14:21, Daniel Fuchs wrote:
> Hi,
>
> Please find below a webrev for fixing
> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
> intermittently
>
> 
>
> Without the fix - it's quite easy to make the test fail - especially
> if you copy paste the @run line a few times.
>
> This test is supposed to detect a deadlock in Logger initialization,
> but it detects too many false positive.
> An analysis of stack traces that the test dumps when it fails shows
> that there is actually no deadlock, since one of the two supposed
> deadlock threads is RUNNABLE.
>
> However - this - I think - indicates a bug in
> ThreadMXBean.findDeadlockedThreads().
>
> I have rewritten the test to sanitize the results before
> and after calling ThreadMXBean.findDeadlockedThreads().
>
> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
> only if the two threads it monitors are simultaneously blocked
> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
> will verify that all threads found in deadlock by
> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>
> Now - I'm not sure whether this is a good thing or not:
>
> pros: it makes it possible to run this test again - and have a greater
> confidence that if it fails it's because of a genuine deadlock,
> which is desirable.
>
> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
> as it appears the test was testing
> ThreadMXBean.findDeadlockedThreads() more than (or as much
> as) it was testing the Logger implementation.
>
> Does it make sense to push this fix and log a bug against ThreadMXBean?
> Or should I instead plan to add this test to the problem list
> (and re-qualify the bug as an issue in ThreadMXBean)?

I'd be ok to simply file a bug against ThreadMXBean, and put the test on 
the ProblemList.txt for now. It should then be revisited with the bug in 
ThreadMXBean.

-Chris.

>
> guidance appreciated!
>
> best regards,
>
> -- daniel
>
>


From chris.hegarty at oracle.com  Mon Jun 17 14:28:13 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 15:28:13 +0100
Subject: RFR 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
In-Reply-To: <51B9914C.8060102@oracle.com>
References: <51B88AA1.4090701@oracle.com> <51B89CB0.3080503@oracle.com>
	<51B9914C.8060102@oracle.com>
Message-ID: <51BF1CFD.5070105@oracle.com>

I haven't seen any convincing arguments to move away from 
parallelPrefix, or any strong objections to it, so I'll go ahead an 
finalize the API.

-Chris.

On 13/06/2013 10:30, Chris Hegarty wrote:
> On 06/12/2013 05:07 PM, Alan Bateman wrote:
>> On 12/06/2013 15:50, Chris Hegarty wrote:
>>> ...
>> Is the name final? Just curious if other names such as parallelScan have
>> been considered (and discarded).
>
> I think we should be open to discussing the name, but I will have to
> defer to Doug as to whether other names were considered/discarded.
>
> It seems the convention we are adopting for naming these new methods,
> whose implementation is parallelized, is to prefix the name with
> 'parallel' ( parallelSort, parallelSetAll ). Sounds fine. Otherwise I
> would have preferred something like prefixScan(..).
>
> Options so far:
>
> parallelPrefix(..) // what we have today
> parallelScan(..)
> parallelPrefixScan(..) // too long winded??
>
>> "Cumulates in parallel each element ...", I guess I would put a comma
>> before and after "in parallel".
>
> Yes, I will add this.
>
>> Otherwise the API looks good to me.
>
> Thanks Alan,
> -Chris.
>
>>
>> -Alan.
>>
>>
>>


From alan.bateman at oracle.com  Mon Jun 17 14:26:12 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 17 Jun 2013 14:26:12 +0000
Subject: hg: jdk8/tl/jdk: 8016236: Class.getGenericInterfaces performance
	improvement
Message-ID: <20130617142635.6AAF04826C@hg.openjdk.java.net>

Changeset: b0cfde1e70e9
Author:    shade
Date:      2013-06-17 16:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0cfde1e70e9

8016236: Class.getGenericInterfaces performance improvement
Summary: cache more reflective data and lookup results.
Reviewed-by: alanb, plevart, psandoz, dl
Contributed-by: Doug Lea 
    , Aleksey Shipilev 

! src/share/classes/java/lang/Class.java
! src/share/classes/sun/reflect/generics/repository/ClassRepository.java
! src/share/native/java/lang/Class.c



From daniel.fuchs at oracle.com  Mon Jun 17 14:37:13 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Jun 2013 16:37:13 +0200
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
In-Reply-To: <51BF1BB5.9060901@oracle.com>
References: <51BF0D4D.8060608@oracle.com> <51BF1BB5.9060901@oracle.com>
Message-ID: <51BF1F19.9080304@oracle.com>

On 6/17/13 4:22 PM, Chris Hegarty wrote:
> On 17/06/2013 14:21, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a webrev for fixing
>> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
>> intermittently
>>
>> 
>>
>> Without the fix - it's quite easy to make the test fail - especially
>> if you copy paste the @run line a few times.
>>
>> This test is supposed to detect a deadlock in Logger initialization,
>> but it detects too many false positive.
>> An analysis of stack traces that the test dumps when it fails shows
>> that there is actually no deadlock, since one of the two supposed
>> deadlock threads is RUNNABLE.
>>
>> However - this - I think - indicates a bug in
>> ThreadMXBean.findDeadlockedThreads().
>>
>> I have rewritten the test to sanitize the results before
>> and after calling ThreadMXBean.findDeadlockedThreads().
>>
>> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
>> only if the two threads it monitors are simultaneously blocked
>> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
>> will verify that all threads found in deadlock by
>> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>>
>> Now - I'm not sure whether this is a good thing or not:
>>
>> pros: it makes it possible to run this test again - and have a greater
>> confidence that if it fails it's because of a genuine deadlock,
>> which is desirable.
>>
>> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
>> as it appears the test was testing
>> ThreadMXBean.findDeadlockedThreads() more than (or as much
>> as) it was testing the Logger implementation.
>>
>> Does it make sense to push this fix and log a bug against ThreadMXBean?
>> Or should I instead plan to add this test to the problem list
>> (and re-qualify the bug as an issue in ThreadMXBean)?
>
> I'd be ok to simply file a bug against ThreadMXBean, and put the test on
> the ProblemList.txt for now. It should then be revisited with the bug in
> ThreadMXBean.
>
> -Chris.

Thanks Chris. As it turns out there's already a bug for ThreadMXBean.
So I've linked the two together.

best regards,

-- daniel

>
>>
>> guidance appreciated!
>>
>> best regards,
>>
>> -- daniel
>>
>>



From huizhe.wang at oracle.com  Mon Jun 17 16:10:18 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 17 Jun 2013 09:10:18 -0700
Subject: RFR (jaxp): 8016133 : Regression: diff. behavior with user-defined
	SAXParser
In-Reply-To: <51BEE803.10906@oracle.com>
References: <51B69B3D.1070707@oracle.com> <51BEC61B.4090709@oracle.com>
	<51BEE803.10906@oracle.com>
Message-ID: <51BF34EA.1060407@oracle.com>

Thanks Chris, Daniel.

Daniel,  I'm not a reviewer either.  I saw some changesets had my user 
id on the reviewer list and surprised that the gate keeper didn't 
complain. Maybe it would if there hasn't been a real reviewer like Chris 
who's also on the list :-)   So in this case, it won't complain a review 
list like "chegar, dfuchs".  It's good for the record, since I know 
you've reviewed many of my change requests and given great comments.

-Joe

On 6/17/2013 3:42 AM, Chris Hegarty wrote:
> Looks ok to me too Joe.
>
> -Chris.
>
> On 17/06/2013 09:17, Daniel Fuchs wrote:
>> Hi Joe,
>>
>> Looks good to me. Not a reviewer - as you know ;-)
>>
>> -- daniel
>>
>> On 6/11/13 5:36 AM, huizhe wang wrote:
>>> Hi,
>>>
>>> This is a quick fix on a regression caused by a previous patch. The
>>> XMLReaderFactory uses a class variable (_jarread) to indicate if 
>>> service
>>> file has already been read. Along with this variable, there was another
>>> (clsFromJar ) that caches the classname if found in a service file. The
>>> 2nd variable and its use were accidentally removed. As a result, the
>>> following code would return the 3rd party impl on first call but then
>>> fall back to the default impl on subsequent calls because reading
>>> service file was skipped when _jarread is true:
>>> XMLReader reader = XMLReaderFactory.createXMLReader();
>>> System.out.println("1:" + reader.getClass().getName());
>>>
>>> XMLReader reader2 = XMLReaderFactory.createXMLReader();
>>> System.out.println("2:" + reader2.getClass().getName());
>>>
>>> The fix is simply recover the original code. Here's the webrev:
>>>
>>> http://cr.openjdk.java.net/~joehw/jdk8/8016133/webrev/
>>>
>>> Thanks,
>>> Joe
>>



From mandy.chung at oracle.com  Mon Jun 17 16:15:30 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Jun 2013 09:15:30 -0700
Subject: RFR 623 build warnings [deprecation] isLoggable(int) in
	PlatformLogger
In-Reply-To: <51BB3008.8000306@oracle.com>
References: <51BB3008.8000306@oracle.com>
Message-ID: <51BF3622.4060809@oracle.com>

Chris,

Thanks for the patch.  It looks fine to me.  I saw that you have pushed 
this changeset which is fine.

As for the background, we leave these deprecated methods and fields in 
sun.util.logging.PlatformLogger just  temporarily to allow JavaFX to 
migrate and use the PlatformLogger.Level enums [1] which has recently be 
fixed.

These deprecated methods/fields will be removed in JDK8:
    JDK-8011638: Remove deprecated methods in 
sun.util.logging.PlatformLogger

Mandy
[1] https://javafx-jira.kenai.com/browse/RT-29523

On 6/14/2013 8:00 AM, Chris Hegarty wrote:
> There are 623 occurrences, and hence 623 deprecated build warnings, of 
> PlatformLogger.isLoggable(int) in the jdk source.
>
> PlatformLogger is an internal API, and used in may places in the jdk. 
> isLoggable(int) has been deprecated in favor of isLoggable(Level). 
> isLoggable(Level) is slightly more efficient, as it avoids the mapping 
> of int to Level.
>
> The solution is to simply replace isLoggable(int) with 
> isLoggable(Level), providing the appropriate Level. Example:
>
>   -          if(logger.isLoggable(PlatformLogger.FINE)) {
>   +          if(logger.isLoggable(PlatformLogger.Level.FINE)) {
>
> http://cr.openjdk.java.net/~chegar/platLoggerWarn/webrev/
>
> I haven't yet filed a bug for this, but I plan to push the changes 
> through TL, rather than splitting the across multiple integration 
> forests.
>
> Sample warning output:
>
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:416: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:422: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:635: 
> warning: [deprecation] isLoggable(int) in PlatformLogger has been 
> deprecated
> ....
>
> -Chris.
>
>
>
>
>



From brian.burkhalter at oracle.com  Mon Jun 17 16:32:42 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jun 2013 09:32:42 -0700
Subject: mercurial mq  Re: RFR 8010325 : Remove hash32() method and
	hash32 int field from java.lang.String
In-Reply-To: <6E71BF94-59D6-4757-896F-127AA5DA5289@oracle.com>
References: <51B7896A.70109@oracle.com>
	
	<51B934A9.8000103@oracle.com> <51BA21B0.8030008@oracle.com>
	
	<6E71BF94-59D6-4757-896F-127AA5DA5289@oracle.com>
Message-ID: <7E50A88A-C414-4E2F-951C-EEF69A5FA1E3@oracle.com>


On Jun 17, 2013, at 2:18 AM, Paul Sandoz wrote:

>> Hmmm.... I've been using mq for so long it's hard for me to imagine working
>> without it.
>> 
>> It allows others to review the mercurial changeset metadata, which is also
>> the best summary to decide whether to review further.
> 
> 
> +1 
> 
> mq is the best way i have found to keep multiple patches in flight either in the same queue or using multiple queues, and avoid those annoying merge commits.

+1

I've started using the "-l" option of "qnew" to create the changeset comment. This can later be updated by directly editing the patch file in .hg/patches, for example to specify the final reviewer(s).

Brian

From mike.duigou at oracle.com  Mon Jun 17 16:42:06 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 17 Jun 2013 16:42:06 +0000
Subject: hg: jdk8/tl: 8016572: Pass CONCURRENCY=$(JOBS) to test/Makefile
Message-ID: <20130617164206.AE98D48276@hg.openjdk.java.net>

Changeset: f8770fe60d53
Author:    mduigou
Date:      2013-06-17 09:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f8770fe60d53

8016572: Pass CONCURRENCY=$(JOBS) to test/Makefile
Reviewed-by: alanb, erikj

! common/makefiles/Main.gmk



From mark.reinhold at oracle.com  Mon Jun 17 16:43:26 2013
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 17 Jun 2013 09:43:26 -0700
Subject: mercurial mq  Re: RFR 8010325 : Remove hash32() method
	and	hash32 int field from java.lang.String
In-Reply-To: <7E50A88A-C414-4E2F-951C-EEF69A5FA1E3@oracle.com>
References: <51B7896A.70109@oracle.com>,
	,
	<51B934A9.8000103@oracle.com>, <51BA21B0.8030008@oracle.com>,
	,
	<6E71BF94-59D6-4757-896F-127AA5DA5289@oracle.com>,
	<7E50A88A-C414-4E2F-951C-EEF69A5FA1E3@oracle.com>
Message-ID: <20130617094326.292877@eggemoggin.niobe.net>

2013/6/17 2:32 -0700, brian.burkhalter at oracle.com:
> On Jun 17, 2013, at 2:18 AM, Paul Sandoz wrote:
>> +1 
>> 
>> mq is the best way i have found to keep multiple patches in flight
>> either in the same queue or using multiple queues, and avoid those
>> annoying merge commits.
> 
> +1
> 
> I've started using the "-l" option of "qnew" to create the changeset
> comment. This can later be updated by directly editing the patch file
> in .hg/patches, for example to specify the final reviewer(s).

To update the changeset comment you can also use the -e, -m, or -l
option with the qrefresh subcommand.

- Mark


From brian.burkhalter at oracle.com  Mon Jun 17 16:54:26 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jun 2013 09:54:26 -0700
Subject: mercurial mq  Re: RFR 8010325 : Remove hash32() method and
	hash32 int field from java.lang.String
In-Reply-To: <20130617094326.292877@eggemoggin.niobe.net>
References: <51B7896A.70109@oracle.com>,
	,
	<51B934A9.8000103@oracle.com>, <51BA21B0.8030008@oracle.com>,
	,
	<6E71BF94-59D6-4757-896F-127AA5DA5289@oracle.com>,
	<7E50A88A-C414-4E2F-951C-EEF69A5FA1E3@oracle.com>
	<20130617094326.292877@eggemoggin.niobe.net>
Message-ID: 

On Jun 17, 2013, at 9:43 AM, mark.reinhold at oracle.com wrote:

>> I've started using the "-l" option of "qnew" to create the changeset
>> comment. This can later be updated by directly editing the patch file
>> in .hg/patches, for example to specify the final reviewer(s).
> 
> To update the changeset comment you can also use the -e, -m, or -l
> option with the qrefresh subcommand.

Ah, that's better.

Thanks,

Brian

From mandy.chung at oracle.com  Mon Jun 17 17:11:34 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Jun 2013 10:11:34 -0700
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
In-Reply-To: <51BF0D4D.8060608@oracle.com>
References: <51BF0D4D.8060608@oracle.com>
Message-ID: <51BF4346.4080805@oracle.com>

FYI. Staffan has a fix in hotspot for JDK-8016304 the ThreadMXBean issue 
[1].

Thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html

On 6/17/2013 6:21 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a webrev for fixing
> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing 
> intermittently
>
> 
>
> Without the fix - it's quite easy to make the test fail - especially
> if you copy paste the @run line a few times.
>
> This test is supposed to detect a deadlock in Logger initialization,
> but it detects too many false positive.
> An analysis of stack traces that the test dumps when it fails shows
> that there is actually no deadlock, since one of the two supposed
> deadlock threads is RUNNABLE.
>
> However - this - I think - indicates a bug in
> ThreadMXBean.findDeadlockedThreads().
>
> I have rewritten the test to sanitize the results before
> and after calling ThreadMXBean.findDeadlockedThreads().
>
> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
> only if the two threads it monitors are simultaneously blocked
> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
> will verify that all threads found in deadlock by 
> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>
> Now - I'm not sure whether this is a good thing or not:
>
> pros: it makes it possible to run this test again - and have a greater
>       confidence that if it fails it's because of a genuine deadlock,
>       which is desirable.
>
> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
>       as it appears the test was testing
>       ThreadMXBean.findDeadlockedThreads() more than (or as much
>       as) it was testing the Logger implementation.
>
> Does it make sense to push this fix and log a bug against ThreadMXBean?
> Or should I instead plan to add this test to the problem list
> (and re-qualify the bug as an issue in ThreadMXBean)?
>
> guidance appreciated!
>
> best regards,
>
> -- daniel
>
>



From david.r.chase at oracle.com  Mon Jun 17 17:15:38 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 17 Jun 2013 13:15:38 -0400
Subject: Inefficient code of String.indexOf(String)
In-Reply-To: 
References: 
	
Message-ID: <8F02D3B8-FBC8-4E6D-9CAD-7C75EE2514DD@oracle.com>

For sufficiently large strings, indexOf can also be profitably parallelized.

David

On 2013-06-17, at 2:14 AM, Martin Buchholz  wrote:

> You are not the first person to have this idea.
> It is unlikely that you will succeed in changing the algorithm, because the
> jit-optimized brute-force algorithm is "almost always" faster.
> But go ahead and prove me wrong!
> 
> 
> On Sun, Jun 16, 2013 at 3:53 AM, Anubhav Chaturvedi <
> mailforanubhav at gmail.com> wrote:
> 
>> Hello,
>> 
>> I have recently started to explore the source code and am new to the open
>> source community. I observed that in String.class within java.lang , the
>> indexOf method, line 1715, uses the bruteforce approach when it comes to
>> string matching. This method is used by the contains(CharSequence) method.
>> There are a number of algorithms that can perform the task more
>> efficiently.
>> 
>> I would like to bring the required changes and needed your advice on this.



From daniel.fuchs at oracle.com  Mon Jun 17 17:36:30 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 17 Jun 2013 19:36:30 +0200
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
In-Reply-To: <51BF4346.4080805@oracle.com>
References: <51BF0D4D.8060608@oracle.com> <51BF4346.4080805@oracle.com>
Message-ID: <51BF491E.6060702@oracle.com>

On 6/17/13 7:11 PM, Mandy Chung wrote:
> FYI. Staffan has a fix in hotspot for JDK-8016304 the ThreadMXBean issue
> [1].

Thanks Mandy.

Yes I saw that. I will wait for Staffan's fix - revert my changes, and
run the test again - and see what I get.

Alternatively I could now modify the test to try & detect JDK-8016304
too and throw an exception pointing at 8016304 if the thread ids
returned by findDeadlockedThread do not seem to indicate a deadlock.

-- daniel

>
> Thanks
> Mandy
> [1]
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html
>
>
> On 6/17/2013 6:21 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a webrev for fixing
>> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
>> intermittently
>>
>> 
>>
>> Without the fix - it's quite easy to make the test fail - especially
>> if you copy paste the @run line a few times.
>>
>> This test is supposed to detect a deadlock in Logger initialization,
>> but it detects too many false positive.
>> An analysis of stack traces that the test dumps when it fails shows
>> that there is actually no deadlock, since one of the two supposed
>> deadlock threads is RUNNABLE.
>>
>> However - this - I think - indicates a bug in
>> ThreadMXBean.findDeadlockedThreads().
>>
>> I have rewritten the test to sanitize the results before
>> and after calling ThreadMXBean.findDeadlockedThreads().
>>
>> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
>> only if the two threads it monitors are simultaneously blocked
>> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
>> will verify that all threads found in deadlock by
>> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>>
>> Now - I'm not sure whether this is a good thing or not:
>>
>> pros: it makes it possible to run this test again - and have a greater
>>       confidence that if it fails it's because of a genuine deadlock,
>>       which is desirable.
>>
>> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
>>       as it appears the test was testing
>>       ThreadMXBean.findDeadlockedThreads() more than (or as much
>>       as) it was testing the Logger implementation.
>>
>> Does it make sense to push this fix and log a bug against ThreadMXBean?
>> Or should I instead plan to add this test to the problem list
>> (and re-qualify the bug as an issue in ThreadMXBean)?
>>
>> guidance appreciated!
>>
>> best regards,
>>
>> -- daniel
>>
>>
>



From kurchi.subhra.hazra at oracle.com  Mon Jun 17 17:45:12 2013
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Mon, 17 Jun 2013 10:45:12 -0700
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51BC1031.3060606@oracle.com>
References: <51BB9065.4070704@oracle.com> <51BBA06A.7060106@oracle.com>
	<51BC1031.3060606@oracle.com>
Message-ID: <51BF4B28.8040301@oracle.com>


On 6/14/2013 11:56 PM, Alan Bateman wrote:
> On 14/06/2013 23:59, Kurchi Hazra wrote:
>>
>> Hi,
>> This is to elimnate the overrides warning from ClassDeclaration.java. 
>> This class is used by rmi, but sun/tools/java and
>> sun/tools/javac also heavily uses it, let me know if anyone else 
>> should also be reviewing it.
>>
>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
>> Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/
>>
>> Thanks,
>> Kurchi
> This looks okay for the purposes of squashing the warning but the 
> existing equals method does look suspect. It might not matter for the 
> rmic usage but as the equals doesn't take account of the the 
> "definition" then it looks to me that it consider very different 
> ClassDeclarations as equals. It would be good to understand how it is 
> used to see whether we have an issue here or not.
Thanks for the review.
If you analyse "definition", it is not constant and changes as the state 
of the class changes (whether binary class is loaded, whether it
has been compiled and so on) - and so does the status field. The type 
field looks like the only good candidate to use in the equals method -
so the equals() looks correct to me.
Now the question is whether there is any need of overriding 
Object.equals() at all, that is, whether each ClassDeclaration object should
be treated as a unique one - I am looking around in the source code to 
check that.

Thanks,
- Kurchi


From brian.burkhalter at oracle.com  Mon Jun 17 18:25:33 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jun 2013 11:25:33 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
Message-ID: 

I am unable at the moment to copy anything to cr.openjdk.java.net so I am including the webrev as a patch below. I'll copy it to the online location as soon as possible.

The patch included at the end of this message fixes this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131192

Code review of the source and accompanying test was effected and all pertinent regression tests passed. Previous performance testing showed a massive improvement:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014697.html

Note that as correctness testing of 7131192 depends on the patch

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html

having already been applied, the present fix cannot be integrated until this prior patch has been applied.

Thanks,

Brian

# HG changeset patch
# Parent 35d5a218004fb1fc64c92fd3151d0a48d4f378e9
7131192: BigInteger.doubleValue() is depressingly slow.
Summary: Replace invocations Double.parseDouble(toString()) and Float.parseFloat(toString()) with direct implementation of conversion from signum and mag.
Reviewed-by: TBD
Contributed-by: Louis Wasserman 

diff -r 35d5a218004f src/share/classes/java/math/BigInteger.java
--- a/src/share/classes/java/math/BigInteger.java	Thu Jun 13 14:18:52 2013 -0700
+++ b/src/share/classes/java/math/BigInteger.java	Fri Jun 14 14:10:43 2013 -0700
@@ -33,6 +33,9 @@
 import java.io.*;
 import java.util.Arrays;
 
+import sun.misc.DoubleConsts;
+import sun.misc.FloatConsts;
+
 /**
  * Immutable arbitrary-precision integers.  All operations behave as if
  * BigIntegers were represented in two's-complement notation (like Java's
@@ -2966,8 +2969,72 @@
      * @return this BigInteger converted to a {@code float}.
      */
     public float floatValue() {
-        // Somewhat inefficient, but guaranteed to work.
-        return Float.parseFloat(this.toString());
+        if (signum == 0) {
+            return 0.0f;
+        }
+
+        int exponent = ((mag.length - 1) << 5) + bitLengthForInt(mag[0]) - 1;
+
+        // exponent == floor(log2(abs(this)))
+        if (exponent < Long.SIZE - 1) {
+            return longValue();
+        } else if (exponent > Float.MAX_EXPONENT) {
+            return signum > 0 ? Float.POSITIVE_INFINITY : Float.NEGATIVE_INFINITY;
+        }
+
+        /*
+         * We need the top SIGNIFICAND_BITS + 1 bits, including the "implicit"
+         * one bit. To make rounding easier, we pick out the top
+         * SIGNIFICAND_BITS + 2 bits, so we have one to help us round up or
+         * down. twiceSignifFloor will contain the top SIGNIFICAND_BITS + 2
+         * bits, and signifFloor the top SIGNIFICAND_BITS + 1.
+         * 
+         * It helps to consider the real number signif = abs(this) *
+         * 2^(SIGNIFICAND_BITS - exponent).
+         */
+        int shift = exponent - FloatConsts.SIGNIFICAND_WIDTH;
+
+        int twiceSignifFloor;
+        // twiceSignifFloor will be == abs().shiftRight(shift).intValue()
+        // We do the shift into an int directly to improve performance.
+
+        int nBits = shift & 0x1f;
+        int nBits2 = 32 - nBits;
+
+        if (nBits == 0) {
+            twiceSignifFloor = mag[0];
+        } else {
+            twiceSignifFloor = mag[0] >>> nBits;
+            if (twiceSignifFloor == 0) {
+                twiceSignifFloor = (mag[0] << nBits2) | (mag[1] >>> nBits);
+            }
+        }
+
+        int signifFloor = twiceSignifFloor >> 1;
+        signifFloor &= FloatConsts.SIGNIF_BIT_MASK; // remove the implied bit
+
+        /*
+         * We round up if either the fractional part of signif is strictly
+         * greater than 0.5 (which is true if the 0.5 bit is set and any lower
+         * bit is set), or if the fractional part of signif is >= 0.5 and
+         * signifFloor is odd (which is true if both the 0.5 bit and the 1 bit
+         * are set). This is equivalent to the desired HALF_EVEN rounding.
+         */
+        boolean increment = (twiceSignifFloor & 1) != 0
+                && ((signifFloor & 1) != 0 || abs().getLowestSetBit() < shift);
+        int signifRounded = increment ? signifFloor + 1 : signifFloor;
+        int bits = ((exponent + FloatConsts.EXP_BIAS)) 
+                << (FloatConsts.SIGNIFICAND_WIDTH - 1);
+        bits += signifRounded;
+        /*
+         * If signifRounded == 2^24, we'd need to set all of the significand
+         * bits to zero and add 1 to the exponent. This is exactly the behavior
+         * we get from just adding signifRounded to bits directly. If the
+         * exponent is Float.MAX_EXPONENT, we round up (correctly) to
+         * Float.POSITIVE_INFINITY.
+         */
+        bits |= signum & FloatConsts.SIGN_BIT_MASK;
+        return Float.intBitsToFloat(bits);
     }
 
     /**
@@ -2986,8 +3053,80 @@
      * @return this BigInteger converted to a {@code double}.
      */
     public double doubleValue() {
-        // Somewhat inefficient, but guaranteed to work.
-        return Double.parseDouble(this.toString());
+        if (signum == 0) {
+            return 0.0;
+        }
+
+        int exponent = ((mag.length - 1) << 5) + bitLengthForInt(mag[0]) - 1;
+
+        // exponent == floor(log2(abs(this))Double)
+        if (exponent < Long.SIZE - 1) {
+            return longValue();
+        } else if (exponent > Double.MAX_EXPONENT) {
+            return signum > 0 ? Double.POSITIVE_INFINITY : Double.NEGATIVE_INFINITY;
+        }
+
+        /*
+         * We need the top SIGNIFICAND_BITS + 1 bits, including the "implicit"
+         * one bit. To make rounding easier, we pick out the top
+         * SIGNIFICAND_BITS + 2 bits, so we have one to help us round up or
+         * down. twiceSignifFloor will contain the top SIGNIFICAND_BITS + 2
+         * bits, and signifFloor the top SIGNIFICAND_BITS + 1.
+         * 
+         * It helps to consider the real number signif = abs(this) *
+         * 2^(SIGNIFICAND_BITS - exponent).
+         */
+        int shift = exponent - DoubleConsts.SIGNIFICAND_WIDTH;
+
+        long twiceSignifFloor;
+        // twiceSignifFloor will be == abs().shiftRight(shift).longValue()
+        // We do the shift into a long directly to improve performance.
+
+        int nBits = shift & 0x1f;
+        int nBits2 = 32 - nBits;
+
+        int highBits;
+        int lowBits;
+        if (nBits == 0) {
+            highBits = mag[0];
+            lowBits = mag[1];
+        } else {
+            highBits = mag[0] >>> nBits;
+            lowBits = (mag[0] << nBits2) | (mag[1] >>> nBits);
+            if (highBits == 0) {
+                highBits = lowBits;
+                lowBits = (mag[1] << nBits2) | (mag[2] >>> nBits);
+            }
+        }
+
+        twiceSignifFloor = ((highBits & LONG_MASK) << 32)
+                | (lowBits & LONG_MASK);
+
+        long signifFloor = twiceSignifFloor >> 1;
+        signifFloor &= DoubleConsts.SIGNIF_BIT_MASK; // remove the implied bit
+
+        /*
+         * We round up if either the fractional part of signif is strictly
+         * greater than 0.5 (which is true if the 0.5 bit is set and any lower
+         * bit is set), or if the fractional part of signif is >= 0.5 and
+         * signifFloor is odd (which is true if both the 0.5 bit and the 1 bit
+         * are set). This is equivalent to the desired HALF_EVEN rounding.
+         */
+        boolean increment = (twiceSignifFloor & 1) != 0
+                && ((signifFloor & 1) != 0 || abs().getLowestSetBit() < shift);
+        long signifRounded = increment ? signifFloor + 1 : signifFloor;
+        long bits = (long) ((exponent + DoubleConsts.EXP_BIAS)) 
+                << (DoubleConsts.SIGNIFICAND_WIDTH - 1);
+        bits += signifRounded;
+        /*
+         * If signifRounded == 2^53, we'd need to set all of the significand
+         * bits to zero and add 1 to the exponent. This is exactly the behavior
+         * we get from just adding signifRounded to bits directly. If the
+         * exponent is Double.MAX_EXPONENT, we round up (correctly) to
+         * Double.POSITIVE_INFINITY.
+         */
+        bits |= signum & DoubleConsts.SIGN_BIT_MASK;
+        return Double.longBitsToDouble(bits);
     }
 
     /**
diff -r 35d5a218004f test/java/math/BigInteger/PrimitiveConversionTests.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/test/java/math/BigInteger/PrimitiveConversionTests.java	Fri Jun 14 14:10:43 2013 -0700
@@ -0,0 +1,82 @@
+import static java.math.BigInteger.ONE;
+
+import java.math.BigInteger;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.Random;
+
+/**
+ * @test
+ * @bug 7131192
+ * @summary This test ensures that BigInteger.floatValue() and
+ *          BigInteger.doubleValue() behave correctly.
+ * @author Louis Wasserman
+ */
+public class PrimitiveConversionTests {
+    static final List ALL_BIGINTEGER_CANDIDATES;
+
+    static {
+        List samples = new ArrayList<>();
+        // Now add values near 2^N for lots of values of N.
+        for (int exponent : Arrays.asList(0, 1, 2, 3, 4, 5, 6, 7, 31, 32, 33,
+                34, 62, 63, 64, 65, 71, 72, 73, 79, 80, 81, 255, 256, 257, 511,
+                512, 513, Double.MAX_EXPONENT - 1, Double.MAX_EXPONENT,
+                Double.MAX_EXPONENT + 1, 2000, 2001, 2002)) {
+            BigInteger x = ONE.shiftLeft(exponent);
+            for (BigInteger y : Arrays.asList(x, x.add(ONE), x.subtract(ONE))) {
+                samples.add(y);
+                samples.add(y.negate());
+            }
+        }
+
+        Random rng = new Random(1234567);
+        for (int i = 0; i < 2000; i++) {
+            samples.add(new BigInteger(rng.nextInt(2000), rng));
+        }
+
+        ALL_BIGINTEGER_CANDIDATES = Collections.unmodifiableList(samples);
+    }
+
+    public static int testDoubleValue() {
+        int failures = 0;
+        for (BigInteger big : ALL_BIGINTEGER_CANDIDATES) {
+            double expected = Double.parseDouble(big.toString());
+            double actual = big.doubleValue();
+
+            // should be bitwise identical
+            if (Double.doubleToRawLongBits(expected) != Double
+                    .doubleToRawLongBits(actual)) {
+                System.out.println(big);
+                failures++;
+            }
+        }
+        return failures;
+    }
+
+    public static int testFloatValue() {
+        int failures = 0;
+        for (BigInteger big : ALL_BIGINTEGER_CANDIDATES) {
+            float expected = Float.parseFloat(big.toString());
+            float actual = big.floatValue();
+
+            // should be bitwise identical
+            if (Float.floatToRawIntBits(expected) != Float
+                    .floatToRawIntBits(actual)) {
+                System.out.println(big + " " + expected + " " + actual);
+                failures++;
+            }
+        }
+        return failures;
+    }
+
+    public static void main(String[] args) {
+        int failures = testDoubleValue();
+        failures += testFloatValue();
+        if (failures > 0) {
+            throw new RuntimeException("Incurred " + failures
+                    + " failures while testing primitive conversions.");
+        }
+    }
+}

From lowasser at google.com  Mon Jun 17 18:32:11 2013
From: lowasser at google.com (Louis Wasserman)
Date: Mon, 17 Jun 2013 11:32:11 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
Message-ID: 

The comments mention SIGNIFICAND_BITS, which I think should probably be
SIGNIFICAND_WIDTH?


On Mon, Jun 17, 2013 at 11:25 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> I am unable at the moment to copy anything to cr.openjdk.java.net so I am
> including the webrev as a patch below. I'll copy it to the online location
> as soon as possible.
>
> The patch included at the end of this message fixes this issue
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131192
>
> Code review of the source and accompanying test was effected and all
> pertinent regression tests passed. Previous performance testing showed a
> massive improvement:
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014697.html
>
> Note that as correctness testing of 7131192 depends on the patch
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html
>
> having already been applied, the present fix cannot be integrated until
> this prior patch has been applied.
>
> Thanks,
>
> Brian
>
> # HG changeset patch
> # Parent 35d5a218004fb1fc64c92fd3151d0a48d4f378e9
> 7131192: BigInteger.doubleValue() is depressingly slow.
> Summary: Replace invocations Double.parseDouble(toString()) and
> Float.parseFloat(toString()) with direct implementation of conversion from
> signum and mag.
> Reviewed-by: TBD
> Contributed-by: Louis Wasserman 
>
> diff -r 35d5a218004f src/share/classes/java/math/BigInteger.java
> --- a/src/share/classes/java/math/BigInteger.java       Thu Jun 13
> 14:18:52 2013 -0700
> +++ b/src/share/classes/java/math/BigInteger.java       Fri Jun 14
> 14:10:43 2013 -0700
> @@ -33,6 +33,9 @@
>  import java.io.*;
>  import java.util.Arrays;
>
> +import sun.misc.DoubleConsts;
> +import sun.misc.FloatConsts;
> +
>  /**
>   * Immutable arbitrary-precision integers.  All operations behave as if
>   * BigIntegers were represented in two's-complement notation (like Java's
> @@ -2966,8 +2969,72 @@
>       * @return this BigInteger converted to a {@code float}.
>       */
>      public float floatValue() {
> -        // Somewhat inefficient, but guaranteed to work.
> -        return Float.parseFloat(this.toString());
> +        if (signum == 0) {
> +            return 0.0f;
> +        }
> +
> +        int exponent = ((mag.length - 1) << 5) + bitLengthForInt(mag[0])
> - 1;
> +
> +        // exponent == floor(log2(abs(this)))
> +        if (exponent < Long.SIZE - 1) {
> +            return longValue();
> +        } else if (exponent > Float.MAX_EXPONENT) {
> +            return signum > 0 ? Float.POSITIVE_INFINITY :
> Float.NEGATIVE_INFINITY;
> +        }
> +
> +        /*
> +         * We need the top SIGNIFICAND_BITS + 1 bits, including the
> "implicit"
> +         * one bit. To make rounding easier, we pick out the top
> +         * SIGNIFICAND_BITS + 2 bits, so we have one to help us round up
> or
> +         * down. twiceSignifFloor will contain the top SIGNIFICAND_BITS +
> 2
> +         * bits, and signifFloor the top SIGNIFICAND_BITS + 1.
> +         *
> +         * It helps to consider the real number signif = abs(this) *
> +         * 2^(SIGNIFICAND_BITS - exponent).
> +         */
> +        int shift = exponent - FloatConsts.SIGNIFICAND_WIDTH;
> +
> +        int twiceSignifFloor;
> +        // twiceSignifFloor will be == abs().shiftRight(shift).intValue()
> +        // We do the shift into an int directly to improve performance.
> +
> +        int nBits = shift & 0x1f;
> +        int nBits2 = 32 - nBits;
> +
> +        if (nBits == 0) {
> +            twiceSignifFloor = mag[0];
> +        } else {
> +            twiceSignifFloor = mag[0] >>> nBits;
> +            if (twiceSignifFloor == 0) {
> +                twiceSignifFloor = (mag[0] << nBits2) | (mag[1] >>>
> nBits);
> +            }
> +        }
> +
> +        int signifFloor = twiceSignifFloor >> 1;
> +        signifFloor &= FloatConsts.SIGNIF_BIT_MASK; // remove the implied
> bit
> +
> +        /*
> +         * We round up if either the fractional part of signif is strictly
> +         * greater than 0.5 (which is true if the 0.5 bit is set and any
> lower
> +         * bit is set), or if the fractional part of signif is >= 0.5 and
> +         * signifFloor is odd (which is true if both the 0.5 bit and the
> 1 bit
> +         * are set). This is equivalent to the desired HALF_EVEN rounding.
> +         */
> +        boolean increment = (twiceSignifFloor & 1) != 0
> +                && ((signifFloor & 1) != 0 || abs().getLowestSetBit() <
> shift);
> +        int signifRounded = increment ? signifFloor + 1 : signifFloor;
> +        int bits = ((exponent + FloatConsts.EXP_BIAS))
> +                << (FloatConsts.SIGNIFICAND_WIDTH - 1);
> +        bits += signifRounded;
> +        /*
> +         * If signifRounded == 2^24, we'd need to set all of the
> significand
> +         * bits to zero and add 1 to the exponent. This is exactly the
> behavior
> +         * we get from just adding signifRounded to bits directly. If the
> +         * exponent is Float.MAX_EXPONENT, we round up (correctly) to
> +         * Float.POSITIVE_INFINITY.
> +         */
> +        bits |= signum & FloatConsts.SIGN_BIT_MASK;
> +        return Float.intBitsToFloat(bits);
>      }
>
>      /**
> @@ -2986,8 +3053,80 @@
>       * @return this BigInteger converted to a {@code double}.
>       */
>      public double doubleValue() {
> -        // Somewhat inefficient, but guaranteed to work.
> -        return Double.parseDouble(this.toString());
> +        if (signum == 0) {
> +            return 0.0;
> +        }
> +
> +        int exponent = ((mag.length - 1) << 5) + bitLengthForInt(mag[0])
> - 1;
> +
> +        // exponent == floor(log2(abs(this))Double)
> +        if (exponent < Long.SIZE - 1) {
> +            return longValue();
> +        } else if (exponent > Double.MAX_EXPONENT) {
> +            return signum > 0 ? Double.POSITIVE_INFINITY :
> Double.NEGATIVE_INFINITY;
> +        }
> +
> +        /*
> +         * We need the top SIGNIFICAND_BITS + 1 bits, including the
> "implicit"
> +         * one bit. To make rounding easier, we pick out the top
> +         * SIGNIFICAND_BITS + 2 bits, so we have one to help us round up
> or
> +         * down. twiceSignifFloor will contain the top SIGNIFICAND_BITS +
> 2
> +         * bits, and signifFloor the top SIGNIFICAND_BITS + 1.
> +         *
> +         * It helps to consider the real number signif = abs(this) *
> +         * 2^(SIGNIFICAND_BITS - exponent).
> +         */
> +        int shift = exponent - DoubleConsts.SIGNIFICAND_WIDTH;
> +
> +        long twiceSignifFloor;
> +        // twiceSignifFloor will be == abs().shiftRight(shift).longValue()
> +        // We do the shift into a long directly to improve performance.
> +
> +        int nBits = shift & 0x1f;
> +        int nBits2 = 32 - nBits;
> +
> +        int highBits;
> +        int lowBits;
> +        if (nBits == 0) {
> +            highBits = mag[0];
> +            lowBits = mag[1];
> +        } else {
> +            highBits = mag[0] >>> nBits;
> +            lowBits = (mag[0] << nBits2) | (mag[1] >>> nBits);
> +            if (highBits == 0) {
> +                highBits = lowBits;
> +                lowBits = (mag[1] << nBits2) | (mag[2] >>> nBits);
> +            }
> +        }
> +
> +        twiceSignifFloor = ((highBits & LONG_MASK) << 32)
> +                | (lowBits & LONG_MASK);
> +
> +        long signifFloor = twiceSignifFloor >> 1;
> +        signifFloor &= DoubleConsts.SIGNIF_BIT_MASK; // remove the
> implied bit
> +
> +        /*
> +         * We round up if either the fractional part of signif is strictly
> +         * greater than 0.5 (which is true if the 0.5 bit is set and any
> lower
> +         * bit is set), or if the fractional part of signif is >= 0.5 and
> +         * signifFloor is odd (which is true if both the 0.5 bit and the
> 1 bit
> +         * are set). This is equivalent to the desired HALF_EVEN rounding.
> +         */
> +        boolean increment = (twiceSignifFloor & 1) != 0
> +                && ((signifFloor & 1) != 0 || abs().getLowestSetBit() <
> shift);
> +        long signifRounded = increment ? signifFloor + 1 : signifFloor;
> +        long bits = (long) ((exponent + DoubleConsts.EXP_BIAS))
> +                << (DoubleConsts.SIGNIFICAND_WIDTH - 1);
> +        bits += signifRounded;
> +        /*
> +         * If signifRounded == 2^53, we'd need to set all of the
> significand
> +         * bits to zero and add 1 to the exponent. This is exactly the
> behavior
> +         * we get from just adding signifRounded to bits directly. If the
> +         * exponent is Double.MAX_EXPONENT, we round up (correctly) to
> +         * Double.POSITIVE_INFINITY.
> +         */
> +        bits |= signum & DoubleConsts.SIGN_BIT_MASK;
> +        return Double.longBitsToDouble(bits);
>      }
>
>      /**
> diff -r 35d5a218004f
> test/java/math/BigInteger/PrimitiveConversionTests.java
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/test/java/math/BigInteger/PrimitiveConversionTests.java   Fri Jun 14
> 14:10:43 2013 -0700
> @@ -0,0 +1,82 @@
> +import static java.math.BigInteger.ONE;
> +
> +import java.math.BigInteger;
> +import java.util.ArrayList;
> +import java.util.Arrays;
> +import java.util.Collections;
> +import java.util.List;
> +import java.util.Random;
> +
> +/**
> + * @test
> + * @bug 7131192
> + * @summary This test ensures that BigInteger.floatValue() and
> + *          BigInteger.doubleValue() behave correctly.
> + * @author Louis Wasserman
> + */
> +public class PrimitiveConversionTests {
> +    static final List ALL_BIGINTEGER_CANDIDATES;
> +
> +    static {
> +        List samples = new ArrayList<>();
> +        // Now add values near 2^N for lots of values of N.
> +        for (int exponent : Arrays.asList(0, 1, 2, 3, 4, 5, 6, 7, 31, 32,
> 33,
> +                34, 62, 63, 64, 65, 71, 72, 73, 79, 80, 81, 255, 256,
> 257, 511,
> +                512, 513, Double.MAX_EXPONENT - 1, Double.MAX_EXPONENT,
> +                Double.MAX_EXPONENT + 1, 2000, 2001, 2002)) {
> +            BigInteger x = ONE.shiftLeft(exponent);
> +            for (BigInteger y : Arrays.asList(x, x.add(ONE),
> x.subtract(ONE))) {
> +                samples.add(y);
> +                samples.add(y.negate());
> +            }
> +        }
> +
> +        Random rng = new Random(1234567);
> +        for (int i = 0; i < 2000; i++) {
> +            samples.add(new BigInteger(rng.nextInt(2000), rng));
> +        }
> +
> +        ALL_BIGINTEGER_CANDIDATES = Collections.unmodifiableList(samples);
> +    }
> +
> +    public static int testDoubleValue() {
> +        int failures = 0;
> +        for (BigInteger big : ALL_BIGINTEGER_CANDIDATES) {
> +            double expected = Double.parseDouble(big.toString());
> +            double actual = big.doubleValue();
> +
> +            // should be bitwise identical
> +            if (Double.doubleToRawLongBits(expected) != Double
> +                    .doubleToRawLongBits(actual)) {
> +                System.out.println(big);
> +                failures++;
> +            }
> +        }
> +        return failures;
> +    }
> +
> +    public static int testFloatValue() {
> +        int failures = 0;
> +        for (BigInteger big : ALL_BIGINTEGER_CANDIDATES) {
> +            float expected = Float.parseFloat(big.toString());
> +            float actual = big.floatValue();
> +
> +            // should be bitwise identical
> +            if (Float.floatToRawIntBits(expected) != Float
> +                    .floatToRawIntBits(actual)) {
> +                System.out.println(big + " " + expected + " " + actual);
> +                failures++;
> +            }
> +        }
> +        return failures;
> +    }
> +
> +    public static void main(String[] args) {
> +        int failures = testDoubleValue();
> +        failures += testFloatValue();
> +        if (failures > 0) {
> +            throw new RuntimeException("Incurred " + failures
> +                    + " failures while testing primitive conversions.");
> +        }
> +    }
> +}




-- 
Louis Wasserman


From brian.burkhalter at oracle.com  Mon Jun 17 18:34:52 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jun 2013 11:34:52 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
Message-ID: <05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>

Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied" bit?

On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:

> The comments mention SIGNIFICAND_BITS, which I think should probably be SIGNIFICAND_WIDTH?



From lowasser at google.com  Mon Jun 17 18:37:13 2013
From: lowasser at google.com (Louis Wasserman)
Date: Mon, 17 Jun 2013 11:37:13 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: <05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
Message-ID: 

You're right, it'd be WIDTH - 1, but since most of the comments refer to
BITS + 1, that evens out nicely.


On Mon, Jun 17, 2013 at 11:34 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied" bit?
>
> On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:
>
> > The comments mention SIGNIFICAND_BITS, which I think should probably be
> SIGNIFICAND_WIDTH?
>
>


-- 
Louis Wasserman


From brian.burkhalter at oracle.com  Mon Jun 17 18:39:12 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 17 Jun 2013 11:39:12 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
Message-ID: 

I'll update this but without reposting the webrev until I can upload the HTML version.

On Jun 17, 2013, at 11:37 AM, Louis Wasserman wrote:

> You're right, it'd be WIDTH - 1, but since most of the comments refer to BITS + 1, that evens out nicely.
> 
> 
> On Mon, Jun 17, 2013 at 11:34 AM, Brian Burkhalter wrote:
> Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied" bit?
> 
> On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:
> 
> > The comments mention SIGNIFICAND_BITS, which I think should probably be SIGNIFICAND_WIDTH?



From chris.hegarty at oracle.com  Mon Jun 17 18:46:39 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 17 Jun 2013 19:46:39 +0100
Subject: RFR 623 build warnings [deprecation] isLoggable(int) in
	PlatformLogger
In-Reply-To: <51BF3622.4060809@oracle.com>
References: <51BB3008.8000306@oracle.com> <51BF3622.4060809@oracle.com>
Message-ID: <51BF598F.5020407@oracle.com>

On 06/17/2013 05:15 PM, Mandy Chung wrote:
> Chris,
>
> Thanks for the patch.  It looks fine to me.  I saw that you have pushed
> this changeset which is fine.

Thanks for looking at this Mandy, your eyes are welcome here.

> As for the background, we leave these deprecated methods and fields in
> sun.util.logging.PlatformLogger just  temporarily to allow JavaFX to
> migrate and use the PlatformLogger.Level enums [1] which has recently be
> fixed.

Yes, I understand this, and the plan makes sense. I just notice these 
warnings, and decided to clean up the jdk for now.

-Chris.

> These deprecated methods/fields will be removed in JDK8:
>     JDK-8011638: Remove deprecated methods in
> sun.util.logging.PlatformLogger
>
> Mandy
> [1] https://javafx-jira.kenai.com/browse/RT-29523
>
> On 6/14/2013 8:00 AM, Chris Hegarty wrote:
>> There are 623 occurrences, and hence 623 deprecated build warnings, of
>> PlatformLogger.isLoggable(int) in the jdk source.
>>
>> PlatformLogger is an internal API, and used in may places in the jdk.
>> isLoggable(int) has been deprecated in favor of isLoggable(Level).
>> isLoggable(Level) is slightly more efficient, as it avoids the mapping
>> of int to Level.
>>
>> The solution is to simply replace isLoggable(int) with
>> isLoggable(Level), providing the appropriate Level. Example:
>>
>>   -          if(logger.isLoggable(PlatformLogger.FINE)) {
>>   +          if(logger.isLoggable(PlatformLogger.Level.FINE)) {
>>
>> http://cr.openjdk.java.net/~chegar/platLoggerWarn/webrev/
>>
>> I haven't yet filed a bug for this, but I plan to push the changes
>> through TL, rather than splitting the across multiple integration
>> forests.
>>
>> Sample warning output:
>>
>> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:416:
>> warning: [deprecation] isLoggable(int) in PlatformLogger has been
>> deprecated
>> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:422:
>> warning: [deprecation] isLoggable(int) in PlatformLogger has been
>> deprecated
>> tl/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java:635:
>> warning: [deprecation] isLoggable(int) in PlatformLogger has been
>> deprecated
>> ....
>>
>> -Chris.
>>
>>
>>
>>
>>
>


From mailforanubhav at gmail.com  Mon Jun 17 19:08:16 2013
From: mailforanubhav at gmail.com (Anubhav Chaturvedi)
Date: Tue, 18 Jun 2013 00:38:16 +0530
Subject: Inefficient code of String.indexOf(String)
In-Reply-To: <8F02D3B8-FBC8-4E6D-9CAD-7C75EE2514DD@oracle.com>
References: 
	
	<8F02D3B8-FBC8-4E6D-9CAD-7C75EE2514DD@oracle.com>
Message-ID: 

Thank you all for the quick response.
I will perform some tests and get in touch again asap.
On Jun 17, 2013 10:45 PM, "David Chase"  wrote:

> For sufficiently large strings, indexOf can also be profitably
> parallelized.
>
> David
>
> On 2013-06-17, at 2:14 AM, Martin Buchholz  wrote:
>
> > You are not the first person to have this idea.
> > It is unlikely that you will succeed in changing the algorithm, because
> the
> > jit-optimized brute-force algorithm is "almost always" faster.
> > But go ahead and prove me wrong!
> >
> >
> > On Sun, Jun 16, 2013 at 3:53 AM, Anubhav Chaturvedi <
> > mailforanubhav at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I have recently started to explore the source code and am new to the
> open
> >> source community. I observed that in String.class within java.lang , the
> >> indexOf method, line 1715, uses the bruteforce approach when it comes to
> >> string matching. This method is used by the contains(CharSequence)
> method.
> >> There are a number of algorithms that can perform the task more
> >> efficiently.
> >>
> >> I would like to bring the required changes and needed your advice on
> this.
>
>


From huizhe.wang at oracle.com  Mon Jun 17 19:47:43 2013
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Mon, 17 Jun 2013 19:47:43 +0000
Subject: hg: jdk8/tl/jaxp: 8016133: Regression: diff. behavior with
	user-defined SAXParser
Message-ID: <20130617194747.9F15E48286@hg.openjdk.java.net>

Changeset: 09d55894844d
Author:    joehw
Date:      2013-06-17 12:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09d55894844d

8016133: Regression: diff. behavior with user-defined SAXParser
Reviewed-by: chegar, dfuchs

! src/org/xml/sax/helpers/XMLReaderFactory.java



From mike.duigou at oracle.com  Mon Jun 17 19:52:46 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 17 Jun 2013 12:52:46 -0700
Subject: RFR 8015395: NumberFormatException during startup if
	java.lang.Integer.IntegerCache.high set to bad value
In-Reply-To: <11B7797E-3D7F-44AC-BD39-DE85282B06E6@oracle.com>
References: <11B7797E-3D7F-44AC-BD39-DE85282B06E6@oracle.com>
Message-ID: <80E1D2BC-C052-4514-9B27-D7CC2555D50C@oracle.com>


On Jun 12 2013, at 16:45 , Brian Burkhalter wrote:

> As no consensus was achieved, I am following up on this thread from last month
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/017493.html
> 
> The behavior with and without the initially suggested patch http://cr.openjdk.java.net/~bpb/8015395/ for a few examples is listed below. As may be seen, the change suppresses the exception for bad values of the java.lang.Integer.IntegerCache.high property passed on the command line (silently falls back to the default value), but appears not to affect the behavior of the AutoBoxCacheMax property for these same values.
> 
> There was more support expressed in the thread last month for throwing the NumberFormatExceotion rather than ignoring the bad value and falling back silently to the default. I tend to agree with that approach in general, but I think that the question here is really whether the same logic applies to a property such as java.lang.Integer.IntegerCache.high which is not publicly supported but rather intended to be used as an internal conduit.

That the property is not publicly supported is important. The property is supposed to be set only by one user and we can adequately test that usage. Having started with the source I was unaware that the "correct" way to adjust the cache was to use the -XX:AutoBoxCacheMax option!

> Brian
> 
> --- WITH Patch ---
> 
> $ java -Xint -Djava.lang.Integer.IntegerCache.high=888888888888888888888888888 GoodbyeWorld
> Goodbye Cruel World! 
> 
> $ java -Xint -Djava.lang.Integer.IntegerCache.high=1024\-Xmx2g GoodbyeWorld
> Goodbye Cruel World! 
> 
> $ java -Xint -XX:AutoBoxCacheMax=888888888888888888888888888 GoodbyeWorld
> Goodbye Cruel World! 
> 
> $ java -Xint -XX:AutoBoxCacheMax=1024\-Xmx2g GoodbyeWorld
> Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit

I am OK with this outcome. I would still prefer to see an error for the "AutoBoxCacheMax=888888888888888888888888888" case but can live with this result.

Mike



From mandy.chung at oracle.com  Mon Jun 17 21:07:13 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Jun 2013 14:07:13 -0700
Subject: RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java
	failing intermittently
In-Reply-To: <51BF491E.6060702@oracle.com>
References: <51BF0D4D.8060608@oracle.com> <51BF4346.4080805@oracle.com>
	<51BF491E.6060702@oracle.com>
Message-ID: <51BF7A81.2080303@oracle.com>


On 6/17/2013 10:36 AM, Daniel Fuchs wrote:
> On 6/17/13 7:11 PM, Mandy Chung wrote:
>> FYI. Staffan has a fix in hotspot for JDK-8016304 the ThreadMXBean issue
>> [1].
>
> Thanks Mandy.
>
> Yes I saw that. I will wait for Staffan's fix - revert my changes, and
> run the test again - and see what I get.

Perhaps you could pull his change into your local repo and verify if it 
resolves this issue.

Mandy

>
> Alternatively I could now modify the test to try & detect JDK-8016304
> too and throw an exception pointing at 8016304 if the thread ids
> returned by findDeadlockedThread do not seem to indicate a deadlock.
>
> -- daniel
>
>>
>> Thanks
>> Mandy
>> [1]
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html 
>>
>>
>>
>> On 6/17/2013 6:21 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a webrev for fixing
>>> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
>>> intermittently
>>>
>>> 
>>>
>>> Without the fix - it's quite easy to make the test fail - especially
>>> if you copy paste the @run line a few times.
>>>
>>> This test is supposed to detect a deadlock in Logger initialization,
>>> but it detects too many false positive.
>>> An analysis of stack traces that the test dumps when it fails shows
>>> that there is actually no deadlock, since one of the two supposed
>>> deadlock threads is RUNNABLE.
>>>
>>> However - this - I think - indicates a bug in
>>> ThreadMXBean.findDeadlockedThreads().
>>>
>>> I have rewritten the test to sanitize the results before
>>> and after calling ThreadMXBean.findDeadlockedThreads().
>>>
>>> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
>>> only if the two threads it monitors are simultaneously blocked
>>> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
>>> will verify that all threads found in deadlock by
>>> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>>>
>>> Now - I'm not sure whether this is a good thing or not:
>>>
>>> pros: it makes it possible to run this test again - and have a greater
>>>       confidence that if it fails it's because of a genuine deadlock,
>>>       which is desirable.
>>>
>>> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
>>>       as it appears the test was testing
>>>       ThreadMXBean.findDeadlockedThreads() more than (or as much
>>>       as) it was testing the Logger implementation.
>>>
>>> Does it make sense to push this fix and log a bug against ThreadMXBean?
>>> Or should I instead plan to add this test to the problem list
>>> (and re-qualify the bug as an issue in ThreadMXBean)?
>>>
>>> guidance appreciated!
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>
>



From joe.darcy at oracle.com  Mon Jun 17 21:46:18 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 17 Jun 2013 21:46:18 +0000
Subject: hg: jdk8/tl/langtools: 8016779: Fix doclint warnings in
	javax.lang.model
Message-ID: <20130617214622.0771A4828E@hg.openjdk.java.net>

Changeset: b7a10bc02e7a
Author:    darcy
Date:      2013-06-17 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7a10bc02e7a

8016779: Fix doclint warnings in javax.lang.model
Reviewed-by: jjg

! src/share/classes/javax/lang/model/util/ElementScanner6.java
! src/share/classes/javax/lang/model/util/ElementScanner7.java
! src/share/classes/javax/lang/model/util/ElementScanner8.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java



From kurchi.subhra.hazra at oracle.com  Mon Jun 17 23:01:34 2013
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Mon, 17 Jun 2013 16:01:34 -0700
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51BF4B28.8040301@oracle.com>
References: <51BB9065.4070704@oracle.com> <51BBA06A.7060106@oracle.com>
	<51BC1031.3060606@oracle.com> <51BF4B28.8040301@oracle.com>
Message-ID: <51BF954E.20805@oracle.com>

I spent some more time reviewing this, I believe the equals() 
implementation is correct. Given one string, we get a unique
Identifier. The Identifier has the associated Type cached - so given an 
Identifier, we get a unique Type too. One usage of the
ClassDeclaration#equals() method is in ClassDefinition#subClassOf(), 
which walks up the inheritance path of the concerned
class to check if any of those are equal to the argument 
ClassDeclaration (and hence have equal Types)..

- Kurchi

On 6/17/2013 10:45 AM, Kurchi Hazra wrote:
>
> On 6/14/2013 11:56 PM, Alan Bateman wrote:
>> On 14/06/2013 23:59, Kurchi Hazra wrote:
>>>
>>> Hi,
>>> This is to elimnate the overrides warning from 
>>> ClassDeclaration.java. This class is used by rmi, but sun/tools/java 
>>> and
>>> sun/tools/javac also heavily uses it, let me know if anyone else 
>>> should also be reviewing it.
>>>
>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
>>> Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/
>>>
>>> Thanks,
>>> Kurchi
>> This looks okay for the purposes of squashing the warning but the 
>> existing equals method does look suspect. It might not matter for the 
>> rmic usage but as the equals doesn't take account of the the 
>> "definition" then it looks to me that it consider very different 
>> ClassDeclarations as equals. It would be good to understand how it is 
>> used to see whether we have an issue here or not.
> Thanks for the review.
> If you analyse "definition", it is not constant and changes as the 
> state of the class changes (whether binary class is loaded, whether it
> has been compiled and so on) - and so does the status field. The type 
> field looks like the only good candidate to use in the equals method -
> so the equals() looks correct to me.
> Now the question is whether there is any need of overriding 
> Object.equals() at all, that is, whether each ClassDeclaration object 
> should
> be treated as a unique one - I am looking around in the source code to 
> check that.
>
> Thanks,
> - Kurchi



From christian.thalinger at oracle.com  Mon Jun 17 23:25:51 2013
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Mon, 17 Jun 2013 23:25:51 +0000
Subject: hg: jdk8/tl/jdk: 7177472: JSR292: MethodType interning penalizes
	scalability
Message-ID: <20130617232604.9F7844828F@hg.openjdk.java.net>

Changeset: 2b63fda275a3
Author:    twisti
Date:      2013-06-17 16:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b63fda275a3

7177472: JSR292: MethodType interning penalizes scalability
Reviewed-by: twisti
Contributed-by: Aleksey Shipilev 

! src/share/classes/java/lang/invoke/MethodType.java



From mike.duigou at oracle.com  Mon Jun 17 23:30:13 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 17 Jun 2013 16:30:13 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
Message-ID: 


On Jun 17 2013, at 03:09 , Paul Sandoz wrote:

> On Jun 14, 2013, at 11:57 PM, Mike Duigou  wrote:
>> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
>> 
> 
> There are some places where the indentation looks wonky e.g. HashMap & LinkedHashMap changes.

I have restyled all of the diffs to make sure they are clean.

> 
> The LinkedHashMap.forEach/replaceAll methods are checking modCount and throwing CME before the action is called.

Corrected.

> 
> The WeakHashMap.replaceAll method is checking the modCount per bucket, not-per element.

Corrected.

> 
> Are there existing tests for the overriding methods?

I had believed so in Map/Defaults.java but replaceAll was absent. Now corrected in updated webrev

http://cr.openjdk.java.net/~mduigou/JDK-8016446/3/webrev/

I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.

Mike


> Otherwise looks OK.
> 
> Paul.
> 
> 
>> For interference detection the strategy I am advocating is :
>> 
>> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.
>> 
>> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.
>> 
>> Mike
>> 
>> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
>> 
>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>> 
>>> Revised webrev:
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>> 
>>> Mike
>>> 
>>> 
>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>> 
>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>> Hello all;
>>>>> 
>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>> 
>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>> 
>>>>> Mike
>>>> 
>>>> Hi Mike,
>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>> 
>>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>>> so you can not do a modCount check only at the end.
>>>> 
>>>> R?mi
>>>> 
>>>> Here is the diff.
>>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>> @@ -28,6 +28,7 @@
>>>> import java.io.*;
>>>> import java.lang.reflect.ParameterizedType;
>>>> import java.lang.reflect.Type;
>>>> +import java.util.function.BiConsumer;
>>>> import java.util.function.Consumer;
>>>> import java.util.function.BiFunction;
>>>> import java.util.function.Function;
>>>> @@ -2615,6 +2616,54 @@
>>>>  int   capacity()     { return table.length; }
>>>>  float loadFactor()   { return loadFactor;   }
>>>> 
>>>> +
>>>> +    @Override
>>>> +    public void forEach(BiConsumer action) {
>>>> +        Objects.requireNonNull(action);
>>>> +        final int expectedModCount = modCount;
>>>> +        if (nullKeyEntry != null) {
>>>> +            forEachNullKey(expectedModCount, action);
>>>> +        }
>>>> +        Object[] table = this.table;
>>>> +        for(int index = 0; index < table.length; index++) {
>>>> +            Object item = table[index];
>>>> +            if (item == null) {
>>>> +                continue;
>>>> +            }
>>>> +            if (item instanceof HashMap.TreeBin) {
>>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>>> +                continue;
>>>> +            }
>>>> +            @SuppressWarnings("unchecked")
>>>> +            Entry entry = (Entry)item;
>>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>>> +                if (expectedModCount != modCount) {
>>>> +                    throw new ConcurrentModificationException();
>>>> +                }
>>>> +                action.accept(entry.key, entry.value);
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>>> +        while (node != null) {
>>>> +            if (expectedModCount != modCount) {
>>>> +                throw new ConcurrentModificationException();
>>>> +            }
>>>> +            @SuppressWarnings("unchecked")
>>>> +            Entry entry = (Entry)node.entry;
>>>> +            action.accept(entry.key, entry.value);
>>>> +            node = (TreeNode)entry.next;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>>> +        if (expectedModCount != modCount) {
>>>> +            throw new ConcurrentModificationException();
>>>> +        }
>>>> +        action.accept(null, nullKeyEntry.value);
>>>> +    }
>>>> +
>>>>  /**
>>>>   * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>>   */
>>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>> @@ -24,7 +24,8 @@
>>>> */
>>>> 
>>>> package java.util;
>>>> -import java.io.*;
>>>> +
>>>> +import java.util.function.BiConsumer;
>>>> 
>>>> /**
>>>> * 
    Hash table and linked list implementation of the Map interface,
>>>> @@ -470,4 +471,16 @@
>>>>  protected boolean removeEldestEntry(Map.Entry eldest) {
>>>>      return false;
>>>>  }
>>>> +
>>>> +    @Override
>>>> +    public void forEach(BiConsumer action) {
>>>> +        Objects.requireNonNull(action);
>>>> +        int expectedModCount = modCount;
>>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>>> +            if (expectedModCount != modCount) {
>>>> +                throw new ConcurrentModificationException();
>>>> +            }
>>>> +            action.accept(entry.key, entry.value);
>>>> +        }
>>>> +    }
>>>> }
>>>> 
>>>> 
>>> 
>> 
> 



From bradford.wetmore at oracle.com  Tue Jun 18 00:37:09 2013
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Tue, 18 Jun 2013 00:37:09 +0000
Subject: hg: jdk8/tl/jdk: 8014620: Signature.getAlgorithm return null in
	special case
Message-ID: <20130618003723.5C3FD48293@hg.openjdk.java.net>

Changeset: 116050227ee9
Author:    youdwei
Date:      2013-06-17 17:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/116050227ee9

8014620: Signature.getAlgorithm return null in special case
Reviewed-by: wetmore

! src/share/classes/java/security/Signature.java
+ test/java/security/Signature/SignatureGetAlgorithm.java



From david.holmes at oracle.com  Tue Jun 18 02:03:22 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 18 Jun 2013 12:03:22 +1000
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <51BED035.30300@oracle.com>
References: <51BED035.30300@oracle.com>
Message-ID: <51BFBFEA.7020602@oracle.com>

Hi Aleksey,

What is the overall change in memory use for this set of changes ie what 
did we use pre TLR merging and what do we use now?

Thanks,
David

On 17/06/2013 7:00 PM, Aleksey Shipilev wrote:
> Hi,
>
> This is the respin of the RFE filed a month ago:
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
>
> The webrev is here:
>    http://cr.openjdk.java.net/~shade/8014233/webrev.02/
>
> Testing:
>    - JPRT build passes
>    - Linux x86_64/release passes jdk/java/lang jtreg
>    - vm.quick.testlist, vm.quick-gc.testlist on selected platforms
>    - microbenchmarks, see below
>
> The rationale follows.
>
> After we merged ThreadLocalRandom state in the thread, we are now
> missing the padding to prevent false sharing on those heavily-updated
> fields. While the Thread is already large enough to separate two TLR
> states for two distinct threads, we can still get the false sharing with
> other thread fields.
>
> There is the benchmark showcasing this:
>    http://cr.openjdk.java.net/~shade/8014233/threadbench.zip
>
> There are two test cases: first one is only calling its own TLR with
> nextInt() and then the current thread's ID, another test calls *another*
> thread ID, thus inducing the false sharing against another thread's TLR
> state.
>
> On my 2x2 i5 laptop, running Linux x86_64:
>    same:    355 +- 1 ops/usec
>    other:   100 +- 5 ops/usec
>
> Note the decrease in throughput because of the false sharing.
>
> With the patch:
>    same:    359 +- 1 ops/usec
>    other:   356 +- 1 ops/usec
>
> Note the performance is back. We want to evade these spurious decreases
> in performance, due to either unlucky memory layout, or the user code
> (un)intentionally ruining the cache line locality for the updater thread.
>
> Thanks,
> -Aleksey.
>


From robert.field at oracle.com  Tue Jun 18 03:32:06 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 18 Jun 2013 03:32:06 +0000
Subject: hg: jdk8/tl/langtools: 8013789: Compiler should emit bridges in
	interfaces
Message-ID: <20130618033210.063FF48299@hg.openjdk.java.net>

Changeset: 455be95bd1b5
Author:    rfield
Date:      2013-06-17 20:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/455be95bd1b5

8013789: Compiler should emit bridges in interfaces
Summary: paired with 8015402: Lambda metafactory should not attempt to determine bridge methods
Reviewed-by: vromero
Contributed-by: maurizio.cimadamore at oracle.com

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
! test/tools/javac/lambda/methodReference/BridgeMethod.java



From robert.field at oracle.com  Tue Jun 18 03:32:37 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Tue, 18 Jun 2013 03:32:37 +0000
Subject: hg: jdk8/tl/jdk: 8015402: Lambda metafactory should not attempt to
	determine bridge methods
Message-ID: <20130618033249.2C74D4829A@hg.openjdk.java.net>

Changeset: 989049977d04
Author:    rfield
Date:      2013-06-17 20:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04

8015402: Lambda metafactory should not attempt to determine bridge methods
Summary: paired with 8013789: Compiler should emit bridges in interfaces
Reviewed-by: twisti

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java



From mike.duigou at oracle.com  Tue Jun 18 04:43:42 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 17 Jun 2013 21:43:42 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: <0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
Message-ID: <277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>

Now updated again with additional tests and, as these things go, fixes. I was able to use LockStep to exercise the checkedNavigable{Set/Map} and synchronizedNavigable{Set/Map} and wrote a basic emptyNavigableMap test. The testing looks pretty good now and provides quite complete coverage.

I did have to shut off one small bit of the NavigableMap/LockStep test that didn't work for wrapped un-serializable Sets. I don't believe the check it did was that important.

http://cr.openjdk.java.net/~mduigou/JDK-7129185/5/webrev/

Mike

On Jun 14 2013, at 16:31 , Mike Duigou wrote:

> Hi Martin;
> 
> Thanks, as always, for the feedback!
> 
> Louis Wasserman's question about existing methods delegating to newer methods and discussions regarding the serialization impacts with Stuart Marks lead me to reconsider the approach used in revision "3".
> 
> For revision "4" I've replaced most of EmptyNavigableMap/Set with instances of Collections.unmodifiableMap/Set(new TreeMap/Set). The number of classes is smaller and serialization considerations for both now and future backwards compatibility are simpler. Also, since the implementation now largely depends upon TreeMap/TreeSet for getting the subMap/Set bounds issues right it's a lot more likely to be error free.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/4/webrev/
> 
> On Jun 12 2013, at 11:49 , Martin Buchholz wrote:
>> Thanks for doing this.  Arguably, I or Josh or Doug should have done this for jdk6.  It's tedious to get all the details right.
> 
> I am very grateful that some work was left undone for me to do. ;-)
> 
>> Mostly looks good.
>> 
>> I suspect the set returned by emptySortedSet is not serialization-compatible between jdk8 and previous jdks.
> emptySortedSet() was added in an earlier Java 8 changeset (JDK-. There is thankfully no backwards compatibility to previous JDK versions though early adopters of JDK 8 will unfortunately encounter serialization compatibility issues as a result of the changes in 7129185
> 
> Wanting to get this all finished in the Java 8 iteration is a key motivator.
>> Extending EmptySortedSet to also implement NavigableSet ought to be both more compatible and more efficient.  And more tedious!
> This shouldn't be necessary since EmptySortedSet appeared in Java 8
> 
>> The code fragment below doesn't actually work, cuz WeakHashMap is not a NavigableMap.
> Good point. I tried redoing this using a Collections.checkedNavigableMap(new TreeMap()) but quickly decided instead that...
>> It's traditional to only @link to a particular destination once per javadoc block.
>> +     * any {@link NavigableMap} implementation.  There is no need to use this
>> +     * method on a {@link NavigableMap} implementation that already has a
> Since both of the NavigableMap implementations in JDK provide NavigableSet implementations this method is not needed. I had created this class as an intermediate step in earlier refactoring but now conclude that it's not needed. I am removing it. If anyone can think of a good reason to include it, please speak now.
> 
> 
> Mike
> 
>> 
>> On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou  wrote:
>> I've done some further updates based upon feedback. I believe this is now "done" and ready for final review.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/
>> 
>> I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods.
>> 
>> Mike
>> 
>> 
>> On Jun 7 2013, at 10:58 , Mike Duigou wrote:
>> 
>> > Hello all;
>> >
>> > I've incorporated feedback from previous rounds and expect to finalize this addition soon.
>> >
>> > http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/
>> >
>> > Any review feedback or suggestions of additional tests welcome.
>> >
>> > Thanks,
>> >
>> > Mike
>> >
>> >
>> 
>> 
> 



From aleksey.shipilev at oracle.com  Tue Jun 18 06:56:30 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 18 Jun 2013 10:56:30 +0400
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <51BFBFEA.7020602@oracle.com>
References: <51BED035.30300@oracle.com> <51BFBFEA.7020602@oracle.com>
Message-ID: <51C0049E.3070007@oracle.com>

Hi David,

It depends on the scenario we are assessing. For the sake of argument,
let's say every thread had requested TLR.current() at least once.

Before the merge:
 Thread maps for ThreadLocal =~ 32 bytes x #threads
 TLR instances + padding =~ (128 + 8?) bytes x #threads

After the merge:
 TLR fields in Thread + padding =~ (2x128 + 16) x #threads

So, there is the additional footprint cost per Thread; but that seems
abysmal comparing to what native thread already allocates for its native
structures (e.g. stack). Note that @Contended does larger padding
anticipating the hardware prefetchers also turned on (VM can get better
at this though).

Gory details:

**** -XX:-EnableContended: ****

Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.

java.lang.Thread
 offset  size                     type description
      0    12                          (assumed to be the object header
+ first field alignment)
     12     4                      int Thread.priority
     16     8                     long Thread.eetop
     24     8                     long Thread.stackSize
     32     8                     long Thread.nativeParkEventPointer
     40     8                     long Thread.tid
     48     8                     long Thread.threadLocalRandomSeed
     56     4                      int Thread.threadStatus
     60     4                      int Thread.threadLocalRandomProbe
     64     4                      int Thread.threadLocalRandomSecondarySeed
     68     1                  boolean Thread.single_step
     69     1                  boolean Thread.daemon
     70     1                  boolean Thread.stillborn
     71     1                          (alignment/padding gap)
     72     4                   char[] Thread.name
     76     4                   Thread Thread.threadQ
     80     4                 Runnable Thread.target
     84     4              ThreadGroup Thread.group
     88     4              ClassLoader Thread.contextClassLoader
     92     4     AccessControlContext Thread.inheritedAccessControlContext
     96     4           ThreadLocalMap Thread.threadLocals
    100     4           ThreadLocalMap Thread.inheritableThreadLocals
    104     4                   Object Thread.parkBlocker
    108     4            Interruptible Thread.blocker
    112     4                   Object Thread.blockerLock
    116     4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler
    120                                (object boundary, size estimate)
VM reports 120 bytes per instance

**** -XX:+EnableContended: ****

Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.

java.lang.Thread
 offset  size                     type description
      0    12                          (assumed to be the object header
+ first field alignment)
     12     4                      int Thread.priority
     16     8                     long Thread.eetop
     24     8                     long Thread.stackSize
     32     8                     long Thread.nativeParkEventPointer
     40     8                     long Thread.tid
     48     4                      int Thread.threadStatus
     52     1                  boolean Thread.single_step
     53     1                  boolean Thread.daemon
     54     1                  boolean Thread.stillborn
     55     1                          (alignment/padding gap)
     56     4                   char[] Thread.name
     60     4                   Thread Thread.threadQ
     64     4                 Runnable Thread.target
     68     4              ThreadGroup Thread.group
     72     4              ClassLoader Thread.contextClassLoader
     76     4     AccessControlContext Thread.inheritedAccessControlContext
     80     4           ThreadLocalMap Thread.threadLocals
     84     4           ThreadLocalMap Thread.inheritableThreadLocals
     88     4                   Object Thread.parkBlocker
     92     4            Interruptible Thread.blocker
     96     4                   Object Thread.blockerLock
    100     4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler
    104   128                          (alignment/padding gap)
    232     8                     long Thread.threadLocalRandomSeed
    240     4                      int Thread.threadLocalRandomProbe
    244     4                      int Thread.threadLocalRandomSecondarySeed
    248                                (object boundary, size estimate)
VM reports 376 bytes per instance


-Aleksey.

On 06/18/2013 06:03 AM, David Holmes wrote:
> Hi Aleksey,
> 
> What is the overall change in memory use for this set of changes ie what
> did we use pre TLR merging and what do we use now?
> 
> Thanks,
> David
> 
> On 17/06/2013 7:00 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> This is the respin of the RFE filed a month ago:
>>   
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
>>
>> The webrev is here:
>>    http://cr.openjdk.java.net/~shade/8014233/webrev.02/
>>
>> Testing:
>>    - JPRT build passes
>>    - Linux x86_64/release passes jdk/java/lang jtreg
>>    - vm.quick.testlist, vm.quick-gc.testlist on selected platforms
>>    - microbenchmarks, see below
>>
>> The rationale follows.
>>
>> After we merged ThreadLocalRandom state in the thread, we are now
>> missing the padding to prevent false sharing on those heavily-updated
>> fields. While the Thread is already large enough to separate two TLR
>> states for two distinct threads, we can still get the false sharing with
>> other thread fields.
>>
>> There is the benchmark showcasing this:
>>    http://cr.openjdk.java.net/~shade/8014233/threadbench.zip
>>
>> There are two test cases: first one is only calling its own TLR with
>> nextInt() and then the current thread's ID, another test calls *another*
>> thread ID, thus inducing the false sharing against another thread's TLR
>> state.
>>
>> On my 2x2 i5 laptop, running Linux x86_64:
>>    same:    355 +- 1 ops/usec
>>    other:   100 +- 5 ops/usec
>>
>> Note the decrease in throughput because of the false sharing.
>>
>> With the patch:
>>    same:    359 +- 1 ops/usec
>>    other:   356 +- 1 ops/usec
>>
>> Note the performance is back. We want to evade these spurious decreases
>> in performance, due to either unlucky memory layout, or the user code
>> (un)intentionally ruining the cache line locality for the updater thread.
>>
>> Thanks,
>> -Aleksey.
>>



From chris.hegarty at oracle.com  Tue Jun 18 08:57:35 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 18 Jun 2013 09:57:35 +0100
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51BF954E.20805@oracle.com>
References: <51BB9065.4070704@oracle.com> <51BBA06A.7060106@oracle.com>
	<51BC1031.3060606@oracle.com> <51BF4B28.8040301@oracle.com>
	<51BF954E.20805@oracle.com>
Message-ID: <51C020FF.2060400@oracle.com>

For the purposes of this issue, I think your changes to hashCode are in 
line with the equals implementation. Trivially, you could also remove 
the '(obj != null) && ' from equals ;-) Otherwise, looks fine to me.

-Chris.

On 06/18/2013 12:01 AM, Kurchi Hazra wrote:
> I spent some more time reviewing this, I believe the equals()
> implementation is correct. Given one string, we get a unique
> Identifier. The Identifier has the associated Type cached - so given an
> Identifier, we get a unique Type too. One usage of the
> ClassDeclaration#equals() method is in ClassDefinition#subClassOf(),
> which walks up the inheritance path of the concerned
> class to check if any of those are equal to the argument
> ClassDeclaration (and hence have equal Types)..
>
> - Kurchi
>
> On 6/17/2013 10:45 AM, Kurchi Hazra wrote:
>>
>> On 6/14/2013 11:56 PM, Alan Bateman wrote:
>>> On 14/06/2013 23:59, Kurchi Hazra wrote:
>>>>
>>>> Hi,
>>>> This is to elimnate the overrides warning from
>>>> ClassDeclaration.java. This class is used by rmi, but sun/tools/java
>>>> and
>>>> sun/tools/javac also heavily uses it, let me know if anyone else
>>>> should also be reviewing it.
>>>>
>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
>>>> Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/
>>>>
>>>> Thanks,
>>>> Kurchi
>>> This looks okay for the purposes of squashing the warning but the
>>> existing equals method does look suspect. It might not matter for the
>>> rmic usage but as the equals doesn't take account of the the
>>> "definition" then it looks to me that it consider very different
>>> ClassDeclarations as equals. It would be good to understand how it is
>>> used to see whether we have an issue here or not.
>> Thanks for the review.
>> If you analyse "definition", it is not constant and changes as the
>> state of the class changes (whether binary class is loaded, whether it
>> has been compiled and so on) - and so does the status field. The type
>> field looks like the only good candidate to use in the equals method -
>> so the equals() looks correct to me.
>> Now the question is whether there is any need of overriding
>> Object.equals() at all, that is, whether each ClassDeclaration object
>> should
>> be treated as a unique one - I am looking around in the source code to
>> check that.
>>
>> Thanks,
>> - Kurchi
>


From chris.hegarty at oracle.com  Tue Jun 18 10:10:24 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 18 Jun 2013 11:10:24 +0100
Subject: More ProblemList.txt Updates (6/2013)
Message-ID: <51C03210.7020608@oracle.com>

I would like to propose to add 
java/time/test/java/time/format/TestDateTimeTextProvider.java to the 
ProblemList.txt until it can be resolved. 8016623 is filed against it, 
and should remove it from the list along with whatever source changes 
are appropriate.

diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -314,6 +314,13 @@ sun/security/ssl/com/sun/net/ssl/interna

 
############################################################################

+# jdk_time
+
+# 8016623
+java/time/test/java/time/format/TestDateTimeTextProvider.java   generic-all
+
+############################################################################
+
  # jdk_tools


-Chris.


From Alan.Bateman at oracle.com  Tue Jun 18 10:17:15 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Jun 2013 11:17:15 +0100
Subject: More ProblemList.txt Updates (6/2013)
In-Reply-To: <51C03210.7020608@oracle.com>
References: <51C03210.7020608@oracle.com>
Message-ID: <51C033AB.3000701@oracle.com>


This looks okay but I think we have several more java.time tests failing 
at the moment (I assume the javac changes to emit bridge methods but I 
have not looked at it closely).

-Alan.


On 18/06/2013 11:10, Chris Hegarty wrote:
> I would like to propose to add 
> java/time/test/java/time/format/TestDateTimeTextProvider.java to the 
> ProblemList.txt until it can be resolved. 8016623 is filed against it, 
> and should remove it from the list along with whatever source changes 
> are appropriate.
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -314,6 +314,13 @@ sun/security/ssl/com/sun/net/ssl/interna
>
>
> ############################################################################ 
>
>
> +# jdk_time
> +
> +# 8016623
> +java/time/test/java/time/format/TestDateTimeTextProvider.java   
> generic-all
> +
> +############################################################################ 
>
> +
>  # jdk_tools
>
>
> -Chris.



From chris.hegarty at oracle.com  Tue Jun 18 10:19:36 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 18 Jun 2013 11:19:36 +0100
Subject: More ProblemList.txt Updates (6/2013)
In-Reply-To: <51C033AB.3000701@oracle.com>
References: <51C03210.7020608@oracle.com> <51C033AB.3000701@oracle.com>
Message-ID: <51C03438.5080107@oracle.com>

On 06/18/2013 11:17 AM, Alan Bateman wrote:
>
> This looks okay but I think we have several more java.time tests failing
> at the moment (I assume the javac changes to emit bridge methods but I
> have not looked at it closely).

I have not seen these failures recently. Do you have specific changes 
you would like to add as part of this? I just picked on 
TestDateTimeTextProvider.java as it is very noisy, fails on all 
platforms, all of the time.

-Chris.

>
> -Alan.
>
>
> On 18/06/2013 11:10, Chris Hegarty wrote:
>> I would like to propose to add
>> java/time/test/java/time/format/TestDateTimeTextProvider.java to the
>> ProblemList.txt until it can be resolved. 8016623 is filed against it,
>> and should remove it from the list along with whatever source changes
>> are appropriate.
>>
>> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
>> --- a/test/ProblemList.txt
>> +++ b/test/ProblemList.txt
>> @@ -314,6 +314,13 @@ sun/security/ssl/com/sun/net/ssl/interna
>>
>>
>> ############################################################################
>>
>>
>> +# jdk_time
>> +
>> +# 8016623
>> +java/time/test/java/time/format/TestDateTimeTextProvider.java
>> generic-all
>> +
>> +############################################################################
>>
>> +
>>  # jdk_tools
>>
>>
>> -Chris.
>


From sundararajan.athijegannathan at oracle.com  Tue Jun 18 11:21:19 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Tue, 18 Jun 2013 11:21:19 +0000
Subject: hg: jdk8/tl/nashorn: 14 new changesets
Message-ID: <20130618112131.4A1E9482AC@hg.openjdk.java.net>

Changeset: df5d7f34e35e
Author:    hannesw
Date:      2013-06-11 17:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/df5d7f34e35e

8015379: PropertyMap.addProperty() is slow
Reviewed-by: attila, jlaskey

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: aa16622193e1
Author:    jlaskey
Date:      2013-06-12 11:22 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa16622193e1

8016453: loadWithNewGlobal does not allow apply operation
Reviewed-by: hannesw, sundar
Contributed-by: james.laskey at oracle.com

! samples/test.js
! src/jdk/nashorn/internal/objects/Global.java

Changeset: d26e069353c0
Author:    hannesw
Date:      2013-06-12 16:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d26e069353c0

8011893: JS Object builtin prototype is not thread safe
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
+ test/script/basic/JDK-8011893.js
+ test/script/basic/JDK-8011893.js.EXPECTED

Changeset: b0dcc3727fc3
Author:    sundar
Date:      2013-06-13 16:08 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b0dcc3727fc3

8015355: Array.prototype functions don't honour non-writable length and / or index properties
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/objects/NativeEvalError.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeJavaImporter.java
! src/jdk/nashorn/internal/objects/NativeRangeError.java
! src/jdk/nashorn/internal/objects/NativeReferenceError.java
! src/jdk/nashorn/internal/objects/NativeSyntaxError.java
! src/jdk/nashorn/internal/objects/NativeTypeError.java
! src/jdk/nashorn/internal/objects/NativeURIError.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/JSONFunctions.java
! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java
+ test/script/basic/JDK-8015355.js

Changeset: 6d6133ef1fd5
Author:    hannesw
Date:      2013-06-13 12:52 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6d6133ef1fd5

8016518: Parsing of octal string escapes is broken
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/parser/Lexer.java
+ test/script/basic/JDK-8016518.js
+ test/script/basic/JDK-8016518.js.EXPECTED

Changeset: 18362e95e638
Author:    hannesw
Date:      2013-06-13 14:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/18362e95e638

8016522: Numeric literal must not be followed by IdentifierStart
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/parser/Lexer.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/error/JDK-8016522.js
+ test/script/error/JDK-8016522.js.EXPECTED

Changeset: fe80eda7b57e
Author:    hannesw
Date:      2013-06-13 15:26 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe80eda7b57e

8016528: Hex code from escape() should be padded
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/GlobalFunctions.java
+ test/script/basic/JDK-8016528.js
+ test/script/basic/JDK-8016528.js.EXPECTED

Changeset: c5f783d83180
Author:    hannesw
Date:      2013-06-13 20:50 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c5f783d83180

8016542: String.prototype.replace called with function argument should not replace $ patterns
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/objects/NativeRegExp.java
+ test/script/basic/JDK-8016542.js
+ test/script/basic/JDK-8016542.js.EXPECTED

Changeset: 3efa56767847
Author:    lagergren
Date:      2013-06-14 13:53 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3efa56767847

8016235: Use in catch block that may not have been executed in try block caused illegal byte code to be generated
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/parser/Lexer.java
+ test/script/basic/JDK-8016235.js

Changeset: 3d947baa33cc
Author:    sundar
Date:      2013-06-14 21:16 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3d947baa33cc

8016618: script mirror object access should be improved
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/ir/BreakableNode.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java
+ test/script/basic/JDK-8016618.js
+ test/script/basic/JDK-8016618.js.EXPECTED

Changeset: a2fa56222fa2
Author:    sundar
Date:      2013-06-17 13:56 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a2fa56222fa2

8016550: nashorn.option.no.syntax.extensions has the wrong default
Reviewed-by: hannesw, lagergren

! make/project.properties
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! test/script/basic/moduleload.js

Changeset: bfac80dffc49
Author:    sundar
Date:      2013-06-18 13:25 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bfac80dffc49

Merge


Changeset: 616ab697fcac
Author:    sundar
Date:      2013-06-18 13:45 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/616ab697fcac

8008915: URLReader constructor should allow specifying encoding
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/URLReader.java
! src/jdk/nashorn/internal/runtime/Source.java

Changeset: 2cf438a3a3aa
Author:    sundar
Date:      2013-06-18 13:52 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2cf438a3a3aa

Merge




From dl at cs.oswego.edu  Tue Jun 18 12:19:24 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 18 Jun 2013 08:19:24 -0400
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
Message-ID: <51C0504C.4060700@cs.oswego.edu>

On 06/17/13 19:30, Mike Duigou wrote:

>
> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>

Now synched up on my side.

-Doug



From alexey.utkin at oracle.com  Tue Jun 18 13:30:52 2013
From: alexey.utkin at oracle.com (alexey.utkin at oracle.com)
Date: Tue, 18 Jun 2013 13:30:52 +0000
Subject: hg: jdk8/tl/jdk: 8016046: (process) Strict validation of input should
	be security manager case only [win].
Message-ID: <20130618133105.93034482B2@hg.openjdk.java.net>

Changeset: 956b00d7d4ea
Author:    uta
Date:      2013-06-18 17:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/956b00d7d4ea

8016046: (process) Strict validation of input should be security manager case only [win].
Reviewed-by: alanb, ahgross

! src/windows/classes/java/lang/ProcessImpl.java
! test/java/lang/Runtime/exec/ExecCommand.java



From Alan.Bateman at oracle.com  Tue Jun 18 14:17:31 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Jun 2013 15:17:31 +0100
Subject: More ProblemList.txt Updates (6/2013)
In-Reply-To: <51C03438.5080107@oracle.com>
References: <51C03210.7020608@oracle.com> <51C033AB.3000701@oracle.com>
	<51C03438.5080107@oracle.com>
Message-ID: <51C06BFB.3080605@oracle.com>

On 18/06/2013 11:19, Chris Hegarty wrote:
> On 06/18/2013 11:17 AM, Alan Bateman wrote:
>>
>> This looks okay but I think we have several more java.time tests failing
>> at the moment (I assume the javac changes to emit bridge methods but I
>> have not looked at it closely).
>
> I have not seen these failures recently. Do you have specific changes 
> you would like to add as part of this? I just picked on 
> TestDateTimeTextProvider.java as it is very noisy, fails on all 
> platforms, all of the time.
>
Robert is looking into but I think there may be an issue with the javac 
changes that were pushed last night.

The TestDateTimeTextProvider.java test that you are looking to exclude 
seems to be caused to a recent change for Portuguese, looks like it is 
impacting tests that use Brazil Portuguese. I see Yong has a patch on 
i18n-dev at the moment to sort out another issue in this area. In case, 
I don't when it will be fixed and I don't see a major issue excluding it 
in the mean-time (I agree it is noise).

-Alan


From ivan.gerasimov at oracle.com  Tue Jun 18 16:29:04 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 18 Jun 2013 20:29:04 +0400
Subject: RFR [7021870] GzipInputStream closes underlying stream during
	reading
In-Reply-To: <51929F5C.8080908@oracle.com>
References: <518CA9DD.9060609@oracle.com> <518D792B.504@oracle.com>
	<5190DB56.2000203@oracle.com> <5190EC13.2010000@oracle.com>
	<5191CC98.1020007@oracle.com> <51929F5C.8080908@oracle.com>
Message-ID: <51C08AD0.7060502@oracle.com>

Hello!

I suggest to extend the test to cover the case with malformed input.
Would you please review the suggested change?
http://cr.openjdk.java.net/~igerasim/7021870/0/webrev/

I haven't created the bug id for the change yet.
Will create one if you agree that the change is reasonable.

The main reason to extend the test is to cover the situation when 
ZIS.available() works correctly, but it is not sufficient to prevent the 
underlying stream from been closed.

Sincerely yours,
Ivan

On 15.05.2013 0:32, Ivan Gerasimov wrote:
> Sherman,
>
> Thank you for a detailed explanation.
>
>> It's a fair assessment to say "ZIS.available() is not the only 
>> cause..." though
>> I don't think it's that easy to really "craft" a real test case to 
>> demonstrate the
>> failure with a "malformed" gzip entry inside a zip file.
> I think I found an easy way to do that.
> It's sufficient to create GZIPInputStream with a small buffer of 4 bytes.
> I've traced the code and found that at the time available() is called 
> there was
> exactly 1 byte left in the input stream. Thus it would have returned 
> true even
> if it were implemented more correctly.
>
> What do you think, is it worth adding it to the existing test?
>
>> At least I don't think
>> I can create one without sitting down with some real calculation:-) 
>> Or, I'm
>> missing something in your test case? It appears you will have to have 
>> the
>> inflater of the GZIPInputStream to happen to have only 8 bytes left 
>> in its
>> input buffer as the "remaining" when it is done inflating the gzip 
>> stream,
>> otherwise the this.in.available() will never > 0 (in case of < 8 
>> byte, the trailer
>> reading will trigger the ZIS to "fill", in which the 
>> fixed/non-customizable 512
>> buffer size of ZIS will guarantee to exhaust the whole entry bytes 
>> and result
>> in the this.is.available() to return 0; if n > 8, means all bytes, 
>> including the
>> malformed byte(s) attached, have been in the GZIS.inf's remaining 
>> buffer,
>> so the this.is.available() will now returns 0 as well) which also 
>> means you
>> need the ZipInputStream "happens" to be filled and inflated all bytes 
>> of the
>> "gzip-streamed" entry, except the last one byte (malformed), in its last
>> filling/inflating...
>>
>> It's also arguable that we are now discussing a "malformed" gzip 
>> entry inside
>> a zip stream, which is not exactly the original "regression" that we 
>> are trying
>> to address... 
> Well, my point is that the reported problem was that "GzipInputStream 
> closes
> underlying stream during reading". Having a malformed input with a 
> garbage at
> the end of the gziped entry was just another case that can trigger 
> this problem
> even with fixed ZIS.available().
>
> Sincerely,
> Ivan
>
>> But, given the current GZIS implementation ignores this type of
>> "malformed" stream (un-necessarily attached bytes at the end), it's 
>> reasonable
>> to request that reading from such an gzip-streamed entry of a zip 
>> entry should
>> succeed as well. And the proposed/pushed fix might be the easiest 
>> approach
>> to solve this "malformed gzip stream inside a zip entry" corner case 
>> for now.
>>
>> So I would suggest to consider combining the existing fix + the 
>> available()
>> change (I would need a deep look to see if it has any "compatibility" 
>> impact...)
>>
>> -Sherman
>>
>>
>> On 05/13/2013 06:35 AM, Ivan Gerasimov wrote:
>>> A small correction to the recipe for failure.
>>> The failure is reproduced when a SINGLE byte is appended to the gzip 
>>> archive.
>>> In the scenario below the echo command appends TWO bytes. These two 
>>> bytes are interpreted as a wrong gzip header and get successfully 
>>> ignored.
>>>
>>> On 13.05.2013 16:23, Ivan Gerasimov wrote:
>>>> Hello Sherman!
>>>>
>>>> Thank you for the review!
>>>> While I agree with you that current implementation of 
>>>> ZipInputStream.available() is not what it's supposed to be, I doubt 
>>>> it is the only cause of the issue.
>>>> Please consider the following example.
>>>> Zip archive (z.zip) consists of two entries: f1 and f2.
>>>> f1 - gzip archive concatenated with a couple of bytes (I understand 
>>>> it's malformed gzip archive),
>>>> f2 - let it be a single byte text file.
>>>>
>>>> $ echo a > f1
>>>> $ echo b > f2
>>>> $ gzip f1
>>>> $ echo a >> f1.gz
>>>> $ zip z.zip f1.gz f2
>>>>
>>>> public class ZipMix {
>>>>     private static byte[] rbuf = new byte[1];
>>>>     public static void main(String[] args) throws Throwable {
>>>>         FileInputStream fis = new FileInputStream("z.zip");
>>>>         ZipInputStream zis = new ZipInputStream(fis);
>>>>         System.out.print("-start-\n");
>>>>         if (zis.getNextEntry() != null) {
>>>>             InputStream gis = new GZIPInputStream(zis, 8192);
>>>>             while (gis.read(rbuf) != -1)
>>>>                 System.out.print(new String(rbuf));
>>>>         }
>>>>         if (zis.getNextEntry() != null) { // <--- throws IOException
>>>>             while (zis.read(rbuf) != -1)
>>>>                 System.out.print(new String(rbuf));
>>>>         }
>>>>         System.out.print("\n-finish-\n");
>>>>     }
>>>> }
>>>>
>>>> This code worked well with jdk1.6.20, since GZIPInputStream hadn't 
>>>> tried to read beyond the trailer.
>>>> This breaks with the current jdk, since GZIPInputStream tries to 
>>>> read yet another gzip header after the first trailer, and 
>>>> SequenceInputStream.read() calls the close() method for underlying 
>>>> stream.
>>>> And this would break even with the ZipInputStream.available() fixed.
>>>>
>>>> It seems to me that the root cause here is using 
>>>> SequenceInputStream, which can close the stream during the read() 
>>>> call.
>>>> And this is what my fix was about - to prevent closing of the 
>>>> underlying stream.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>> On 11.05.2013 2:48, Xueming Shen wrote:
>>>>> The proposed fix does solve the issue.
>>>>>
>>>>> However it appears it does not fix the root cause that triggers 
>>>>> this problem.
>>>>> The root cause, or the direct trigger of this bug is the fact that 
>>>>> ZipInputStream
>>>>> .availble() is really NOT reliable to tell us whether or not there 
>>>>> is any byte
>>>>> "available" to be read from the input stream. The api doc of the 
>>>>> ZIS.available()
>>>>> specifies "Returns 0 after EOF has reached for the current entry 
>>>>> data, otherwise
>>>>> always return 1.". The implementation is straightforward,
>>>>>
>>>>>     public int available() throws IOException {
>>>>>         if (entryEOF) {
>>>>>             return 0;
>>>>>         } else {
>>>>>             return 1;
>>>>>         }
>>>>>     }
>>>>>
>>>>> However, the flag "entryEOF" is only set if a read attempt has 
>>>>> been tried
>>>>> and failed (see ZIS.read()), which means if a previous read of the 
>>>>> entry
>>>>> succeeded and it actually read all the available bytes from the 
>>>>> entry (with
>>>>> a big enough buffer), there is 0 byte available for read, the 
>>>>> "flag" is not
>>>>> set, so if you invoke zis.available(), it return 1, but a read() 
>>>>> invocation will
>>>>> returns -1 (yes, if you then try zis.available() again , it 
>>>>> returns the expected
>>>>> 0). The test below demonstrates this issue.
>>>>>
>>>>>    public static void main(String args[]) throws IOException {
>>>>>        ZipInputStream zis = new ZipInputStream(new 
>>>>> FileInputStream(args[0]));
>>>>>        ZipEntry ze;
>>>>>        while((ze = zis.getNextEntry()) !=null) {
>>>>>            System.out.println("--------------" + ze.getName() + 
>>>>> "--------");
>>>>>            byte[] buf = new byte[8102];
>>>>>
>>>>>            while (true) {
>>>>>                System.out.println("    zis.available()=" + 
>>>>> zis.available());
>>>>>                int n = zis.read(buf, 0, buf.length);
>>>>>                System.out.println("    readN=" + n);
>>>>>                if (n == -1)
>>>>>                    break;
>>>>>            }
>>>>>        }
>>>>>
>>>>>     }
>>>>>
>>>>> It is arguable that the this is not an implementation bug, since 
>>>>> it is reasonable
>>>>> to argue that the EOF has not been "really" reached yet after the 
>>>>> first try, the
>>>>> implementation happens to return all available bytes, so the next 
>>>>> read try finally
>>>>> "reached" the EOF, but this obviously is not the expectation.
>>>>>
>>>>> Unfortunately the fix we put in for #4691425 [1] logically depends on
>>>>> in.available() to decide whether or not we need to read a little 
>>>>> further, which
>>>>> directly triggers this bug when the ZIS.available() "lies".
>>>>>
>>>>>         // If there are more bytes available in "in" or
>>>>>         // the leftover in the "inf" is > 26 bytes:
>>>>>         // this.trailer(8) + next.header.min(10) + next.trailer(8)
>>>>>         // try concatenated case
>>>>>         if (this.in.available() > 0 || n > 26) {
>>>>>             ....
>>>>>         }
>>>>>
>>>>> Not only ZInputStream has this issue, its parent class 
>>>>> InflaterStream (and
>>>>> its sibling GZIPInputStream, GZS inherits InflaterStream's 
>>>>> available()
>>>>> implementation directly) has the same issue, I do have a bug#7031075
>>>>> filed against GZIPInputStream.
>>>>>
>>>>> So the proposed fix is more a workaround for this available() 
>>>>> issue. The
>>>>> alternative is to fix the issue directly, for example, to change 
>>>>> the ZIS's
>>>>> available implementation to something like
>>>>>
>>>>>     public int available() throws IOException {
>>>>>         ensureOpen();
>>>>>         if (entryEOF || entry == null)
>>>>>             return 0;
>>>>>         switch (entry.method) {
>>>>>         case DEFLATED:
>>>>>             return (inf.finished() || inf.needsDictionary()) ? 0 : 1;
>>>>>         case STORED:
>>>>>             return remaining > 0 ? 1 : 0;
>>>>>         default:
>>>>>             throw new ZipException("invalid compression method");
>>>>>         }
>>>>>     }
>>>>>
>>>>> we probably should go further to simply remove the flag "entryEOF"
>>>>> and move the "deflated" case implementation into InflaterInputStream
>>>>> (to fix 7031075 as well).
>>>>>
>>>>> -Sherman
>>>>>
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~sherman/4691425/webrev/
>>>>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7031075
>>>>>
>>>>> On 05/10/2013 01:03 AM, Ivan Gerasimov wrote:
>>>>>> Hello everybody!
>>>>>>
>>>>>> GzipInputStream uses SequenceInputStream to concatenate the 
>>>>>> underlying stream with some data that reside in memory.
>>>>>> SequenceInputStream is implementing in such a way that it closes 
>>>>>> the stream when it reaches EOS.
>>>>>>
>>>>>> The solution is to wrap the underlying stream with extended 
>>>>>> FilterInputStream that overrides the close() method.
>>>>>>
>>>>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7021870
>>>>>> WEBREV: http://cr.openjdk.java.net/~dmeetry/7021870/webrev.0/ 
>>>>>> 
>>>>>>
>>>>>> Sincerely your,
>>>>>> Ivan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>



From brent.christian at oracle.com  Tue Jun 18 16:57:19 2013
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 18 Jun 2013 09:57:19 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: <277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
Message-ID: <51C0916F.5020907@oracle.com>

FWIW, the HashMap/LinkedHashMap/Hashtable/WeakHashMap changes look good 
to me.

-Brent

On 6/17/13 9:43 PM, Mike Duigou wrote:
> Now updated again with additional tests and, as these things go, fixes. I was able to use LockStep to exercise the checkedNavigable{Set/Map} and synchronizedNavigable{Set/Map} and wrote a basic emptyNavigableMap test. The testing looks pretty good now and provides quite complete coverage.
>
> I did have to shut off one small bit of the NavigableMap/LockStep test that didn't work for wrapped un-serializable Sets. I don't believe the check it did was that important.
>
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/5/webrev/
>
> Mike
>
> On Jun 14 2013, at 16:31 , Mike Duigou wrote:
>
>> Hi Martin;
>>
>> Thanks, as always, for the feedback!
>>
>> Louis Wasserman's question about existing methods delegating to newer methods and discussions regarding the serialization impacts with Stuart Marks lead me to reconsider the approach used in revision "3".
>>
>> For revision "4" I've replaced most of EmptyNavigableMap/Set with instances of Collections.unmodifiableMap/Set(new TreeMap/Set). The number of classes is smaller and serialization considerations for both now and future backwards compatibility are simpler. Also, since the implementation now largely depends upon TreeMap/TreeSet for getting the subMap/Set bounds issues right it's a lot more likely to be error free.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-7129185/4/webrev/
>>
>> On Jun 12 2013, at 11:49 , Martin Buchholz wrote:
>>> Thanks for doing this.  Arguably, I or Josh or Doug should have done this for jdk6.  It's tedious to get all the details right.
>>
>> I am very grateful that some work was left undone for me to do. ;-)
>>
>>> Mostly looks good.
>>>
>>> I suspect the set returned by emptySortedSet is not serialization-compatible between jdk8 and previous jdks.
>> emptySortedSet() was added in an earlier Java 8 changeset (JDK-. There is thankfully no backwards compatibility to previous JDK versions though early adopters of JDK 8 will unfortunately encounter serialization compatibility issues as a result of the changes in 7129185
>>
>> Wanting to get this all finished in the Java 8 iteration is a key motivator.
>>> Extending EmptySortedSet to also implement NavigableSet ought to be both more compatible and more efficient.  And more tedious!
>> This shouldn't be necessary since EmptySortedSet appeared in Java 8
>>
>>> The code fragment below doesn't actually work, cuz WeakHashMap is not a NavigableMap.
>> Good point. I tried redoing this using a Collections.checkedNavigableMap(new TreeMap()) but quickly decided instead that...
>>> It's traditional to only @link to a particular destination once per javadoc block.
>>> +     * any {@link NavigableMap} implementation.  There is no need to use this
>>> +     * method on a {@link NavigableMap} implementation that already has a
>> Since both of the NavigableMap implementations in JDK provide NavigableSet implementations this method is not needed. I had created this class as an intermediate step in earlier refactoring but now conclude that it's not needed. I am removing it. If anyone can think of a good reason to include it, please speak now.
>>
>>
>> Mike
>>
>>>
>>> On Mon, Jun 10, 2013 at 4:36 PM, Mike Duigou  wrote:
>>> I've done some further updates based upon feedback. I believe this is now "done" and ready for final review.
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-7129185/3/webrev/
>>>
>>> I did find one inconsistency in the implementations SortedSet.headSet and SortedSet.tailSet methods.
>>>
>>> Mike
>>>
>>>
>>> On Jun 7 2013, at 10:58 , Mike Duigou wrote:
>>>
>>>> Hello all;
>>>>
>>>> I've incorporated feedback from previous rounds and expect to finalize this addition soon.
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-7129185/2/webrev/
>>>>
>>>> Any review feedback or suggestions of additional tests welcome.
>>>>
>>>> Thanks,
>>>>
>>>> Mike
>>>>
>>>>
>>>
>>>
>>
>


From vicente.romero at oracle.com  Tue Jun 18 17:58:29 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 18 Jun 2013 17:58:29 +0000
Subject: hg: jdk8/tl/langtools: 8016607: javac,
	avoid analyzing lambdas for source 7 compilation
Message-ID: <20130618175832.6D993482C2@hg.openjdk.java.net>

Changeset: e701af23a095
Author:    vromero
Date:      2013-06-18 18:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e701af23a095

8016607: javac, avoid analyzing lambdas for source 7 compilation
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java



From vicente.romero at oracle.com  Tue Jun 18 18:03:28 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 18 Jun 2013 18:03:28 +0000
Subject: hg: jdk8/tl/langtools: 8016267: javac,
	TypeTag refactoring has provoked performance issues
Message-ID: <20130618180331.3FCF2482C3@hg.openjdk.java.net>

Changeset: 9851071b551a
Author:    vromero
Date:      2013-06-18 19:02 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9851071b551a

8016267: javac, TypeTag refactoring has provoked performance issues
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeTag.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java



From kurchi.subhra.hazra at oracle.com  Tue Jun 18 18:46:25 2013
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Tue, 18 Jun 2013 11:46:25 -0700
Subject: Code Review Request: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
In-Reply-To: <51C020FF.2060400@oracle.com>
References: <51BB9065.4070704@oracle.com> <51BBA06A.7060106@oracle.com>
	<51BC1031.3060606@oracle.com> <51BF4B28.8040301@oracle.com>
	<51BF954E.20805@oracle.com> <51C020FF.2060400@oracle.com>
Message-ID: <51C0AB01.50301@oracle.com>

Yes, I have that removed. Thanks for the review!

- Kurchi

On 6/18/2013 1:57 AM, Chris Hegarty wrote:
> For the purposes of this issue, I think your changes to hashCode are 
> in line with the equals implementation. Trivially, you could also 
> remove the '(obj != null) && ' from equals ;-) Otherwise, looks fine 
> to me.
>
> -Chris.
>
> On 06/18/2013 12:01 AM, Kurchi Hazra wrote:
>> I spent some more time reviewing this, I believe the equals()
>> implementation is correct. Given one string, we get a unique
>> Identifier. The Identifier has the associated Type cached - so given an
>> Identifier, we get a unique Type too. One usage of the
>> ClassDeclaration#equals() method is in ClassDefinition#subClassOf(),
>> which walks up the inheritance path of the concerned
>> class to check if any of those are equal to the argument
>> ClassDeclaration (and hence have equal Types)..
>>
>> - Kurchi
>>
>> On 6/17/2013 10:45 AM, Kurchi Hazra wrote:
>>>
>>> On 6/14/2013 11:56 PM, Alan Bateman wrote:
>>>> On 14/06/2013 23:59, Kurchi Hazra wrote:
>>>>>
>>>>> Hi,
>>>>> This is to elimnate the overrides warning from
>>>>> ClassDeclaration.java. This class is used by rmi, but sun/tools/java
>>>>> and
>>>>> sun/tools/javac also heavily uses it, let me know if anyone else
>>>>> should also be reviewing it.
>>>>>
>>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8016698 [To appear]
>>>>> Webrev: http://cr.openjdk.java.net/~khazra/8016698/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Kurchi
>>>> This looks okay for the purposes of squashing the warning but the
>>>> existing equals method does look suspect. It might not matter for the
>>>> rmic usage but as the equals doesn't take account of the the
>>>> "definition" then it looks to me that it consider very different
>>>> ClassDeclarations as equals. It would be good to understand how it is
>>>> used to see whether we have an issue here or not.
>>> Thanks for the review.
>>> If you analyse "definition", it is not constant and changes as the
>>> state of the class changes (whether binary class is loaded, whether it
>>> has been compiled and so on) - and so does the status field. The type
>>> field looks like the only good candidate to use in the equals method -
>>> so the equals() looks correct to me.
>>> Now the question is whether there is any need of overriding
>>> Object.equals() at all, that is, whether each ClassDeclaration object
>>> should
>>> be treated as a unique one - I am looking around in the source code to
>>> check that.
>>>
>>> Thanks,
>>> - Kurchi
>>

-- 
-Kurchi



From forax at univ-mlv.fr  Tue Jun 18 18:54:37 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 18 Jun 2013 20:54:37 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
Message-ID: <51C0ACED.80805@univ-mlv.fr>

On 06/18/2013 01:30 AM, Mike Duigou wrote:

The webrev looks fine for me.

Nitpicking a little bit, in IdentityHashMap (forEach and replaceAll),
t[index] is processed twice, by example in forEach, it would prefer this 
code:

     public void forEach(BiConsumer action) {
         Objects.requireNonNull(action);
         int expectedModCount = modCount;

         Object[] t = table;
         for (int index = 0; index < t.length; index += 2) {
             Object key = t[index];
             if (key != null) {
                 action.accept((K) unmaskNull(key), (V) t[index + 1]);
             }

             if (modCount != expectedModCount)  {
                 throw new ConcurrentModificationException();
             }
          }
     }

Also there is no curly brace around "throw new CME();"

And I have an open question, in ConcurrentMap, the code use entrySet() 
but could use forEach,
I wonder which one is better here ?

cheers,
R?mi

> On Jun 17 2013, at 03:09 , Paul Sandoz wrote:
>
>> On Jun 14, 2013, at 11:57 PM, Mike Duigou  wrote:
>>> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
>>>
>> There are some places where the indentation looks wonky e.g. HashMap & LinkedHashMap changes.
> I have restyled all of the diffs to make sure they are clean.
>
>> The LinkedHashMap.forEach/replaceAll methods are checking modCount and throwing CME before the action is called.
> Corrected.
>
>> The WeakHashMap.replaceAll method is checking the modCount per bucket, not-per element.
> Corrected.
>
>> Are there existing tests for the overriding methods?
> I had believed so in Map/Defaults.java but replaceAll was absent. Now corrected in updated webrev
>
> http://cr.openjdk.java.net/~mduigou/JDK-8016446/3/webrev/
>
> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>
> Mike
>
>
>> Otherwise looks OK.
>>
>> Paul.
>>
>>
>>> For interference detection the strategy I am advocating is :
>>>
>>> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.
>>>
>>> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.
>>>
>>> Mike
>>>
>>> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
>>>
>>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>>>
>>>> Revised webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>>>
>>>> Mike
>>>>
>>>>
>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>
>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>>
>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>>
>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>>
>>>>>> Mike
>>>>> Hi Mike,
>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>>>
>>>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>>>> so you can not do a modCount check only at the end.
>>>>>
>>>>> R?mi
>>>>>
>>>>> Here is the diff.
>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>> @@ -28,6 +28,7 @@
>>>>> import java.io.*;
>>>>> import java.lang.reflect.ParameterizedType;
>>>>> import java.lang.reflect.Type;
>>>>> +import java.util.function.BiConsumer;
>>>>> import java.util.function.Consumer;
>>>>> import java.util.function.BiFunction;
>>>>> import java.util.function.Function;
>>>>> @@ -2615,6 +2616,54 @@
>>>>>   int   capacity()     { return table.length; }
>>>>>   float loadFactor()   { return loadFactor;   }
>>>>>
>>>>> +
>>>>> +    @Override
>>>>> +    public void forEach(BiConsumer action) {
>>>>> +        Objects.requireNonNull(action);
>>>>> +        final int expectedModCount = modCount;
>>>>> +        if (nullKeyEntry != null) {
>>>>> +            forEachNullKey(expectedModCount, action);
>>>>> +        }
>>>>> +        Object[] table = this.table;
>>>>> +        for(int index = 0; index < table.length; index++) {
>>>>> +            Object item = table[index];
>>>>> +            if (item == null) {
>>>>> +                continue;
>>>>> +            }
>>>>> +            if (item instanceof HashMap.TreeBin) {
>>>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>>>> +                continue;
>>>>> +            }
>>>>> +            @SuppressWarnings("unchecked")
>>>>> +            Entry entry = (Entry)item;
>>>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>>>> +                if (expectedModCount != modCount) {
>>>>> +                    throw new ConcurrentModificationException();
>>>>> +                }
>>>>> +                action.accept(entry.key, entry.value);
>>>>> +            }
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>>>> +        while (node != null) {
>>>>> +            if (expectedModCount != modCount) {
>>>>> +                throw new ConcurrentModificationException();
>>>>> +            }
>>>>> +            @SuppressWarnings("unchecked")
>>>>> +            Entry entry = (Entry)node.entry;
>>>>> +            action.accept(entry.key, entry.value);
>>>>> +            node = (TreeNode)entry.next;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>>>> +        if (expectedModCount != modCount) {
>>>>> +            throw new ConcurrentModificationException();
>>>>> +        }
>>>>> +        action.accept(null, nullKeyEntry.value);
>>>>> +    }
>>>>> +
>>>>>   /**
>>>>>    * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>>>    */
>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>> @@ -24,7 +24,8 @@
>>>>> */
>>>>>
>>>>> package java.util;
>>>>> -import java.io.*;
>>>>> +
>>>>> +import java.util.function.BiConsumer;
>>>>>
>>>>> /**
>>>>> * 
    Hash table and linked list implementation of the Map interface,
>>>>> @@ -470,4 +471,16 @@
>>>>>   protected boolean removeEldestEntry(Map.Entry eldest) {
>>>>>       return false;
>>>>>   }
>>>>> +
>>>>> +    @Override
>>>>> +    public void forEach(BiConsumer action) {
>>>>> +        Objects.requireNonNull(action);
>>>>> +        int expectedModCount = modCount;
>>>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>>>> +            if (expectedModCount != modCount) {
>>>>> +                throw new ConcurrentModificationException();
>>>>> +            }
>>>>> +            action.accept(entry.key, entry.value);
>>>>> +        }
>>>>> +    }
>>>>> }
>>>>>
>>>>>



From chris.hegarty at oracle.com  Tue Jun 18 19:19:40 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:19:40 +0000
Subject: hg: jdk8/tl/hotspot: 11 new changesets
Message-ID: <20130618192002.3A8B5482C8@hg.openjdk.java.net>

Changeset: f75faf51e8c4
Author:    hseigel
Date:      2013-03-07 11:49 -0500
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f75faf51e8c4

7158805: Better rewriting of nested subroutine calls
Reviewed-by: mschoene, coleenp

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/oops/generateOopMap.cpp

Changeset: b295e132102d
Author:    mullan
Date:      2013-04-05 10:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b295e132102d

8001330: Improve on checking order
Reviewed-by: acorn, hawtin

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jvm.cpp

Changeset: be131aa5a529
Author:    mullan
Date:      2013-04-22 08:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/be131aa5a529

8011896: Add check for invalid offset for new AccessControlContext isAuthorized field
Reviewed-by: acorn

! src/share/vm/classfile/javaClasses.cpp

Changeset: 3463b5b373f7
Author:    chegar
Date:      2013-04-24 10:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3463b5b373f7

Merge


Changeset: f822ecf621ce
Author:    chegar
Date:      2013-04-28 08:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f822ecf621ce

Merge


Changeset: 4b52137b07c9
Author:    chegar
Date:      2013-05-01 14:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b52137b07c9

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp

Changeset: 7ee0d5c53c78
Author:    chegar
Date:      2013-05-08 15:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ee0d5c53c78

Merge

- agent/doc/c2replay.html
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp

Changeset: cb92413c6934
Author:    chegar
Date:      2013-05-16 11:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb92413c6934

Merge

! src/share/vm/classfile/vmSymbols.hpp

Changeset: ce9ecec70f99
Author:    chegar
Date:      2013-05-23 12:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce9ecec70f99

Merge

- make/bsd/makefiles/launcher.make
- make/linux/makefiles/launcher.make
- make/solaris/makefiles/launcher.make
- make/windows/makefiles/launcher.make
- src/os/posix/launcher/java_md.c
- src/os/posix/launcher/java_md.h
- src/os/posix/launcher/launcher.script
- src/os/windows/launcher/java_md.c
- src/os/windows/launcher/java_md.h
- src/share/tools/launcher/java.c
- src/share/tools/launcher/java.h
- src/share/tools/launcher/jli_util.c
- src/share/tools/launcher/jli_util.h
- src/share/tools/launcher/wildcard.c
- src/share/tools/launcher/wildcard.h
! src/share/vm/classfile/vmSymbols.hpp
- src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jvm.cpp

Changeset: 0861193d358a
Author:    chegar
Date:      2013-05-31 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0861193d358a

Merge

- agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java
- agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java
- test/runtime/7158804/Test7158804.sh
- test/runtime/8003985/Test8003985.java

Changeset: eaf3742822ec
Author:    chegar
Date:      2013-06-17 11:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eaf3742822ec

Merge

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jvm.cpp



From chris.hegarty at oracle.com  Tue Jun 18 19:21:10 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:21:10 +0000
Subject: hg: jdk8/tl/jaxp: 9 new changesets
Message-ID: <20130618192130.DC5EA482C9@hg.openjdk.java.net>

Changeset: f14f72174f00
Author:    chegar
Date:      2013-04-24 10:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f14f72174f00

Merge


Changeset: b225607e056b
Author:    chegar
Date:      2013-04-28 08:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b225607e056b

Merge


Changeset: 5b7a22859380
Author:    chegar
Date:      2013-05-08 10:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5b7a22859380

Merge


Changeset: 96223058c269
Author:    chegar
Date:      2013-05-16 11:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/96223058c269

Merge


Changeset: ed115f7cc6d0
Author:    chegar
Date:      2013-05-23 12:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ed115f7cc6d0

Merge


Changeset: 231034c73ed5
Author:    chegar
Date:      2013-05-31 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/231034c73ed5

Merge


Changeset: f8f257062d53
Author:    chegar
Date:      2013-06-10 09:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f8f257062d53

Merge

- src/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory
- src/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory
- src/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager
- src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java
- src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java

Changeset: ec38586b8bf3
Author:    chegar
Date:      2013-06-17 11:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ec38586b8bf3

Merge


Changeset: 1c5e3ae28f81
Author:    chegar
Date:      2013-06-18 09:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c5e3ae28f81

Merge




From chris.hegarty at oracle.com  Tue Jun 18 19:18:57 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:18:57 +0000
Subject: hg: jdk8/tl/corba: 9 new changesets
Message-ID: <20130618191903.1DBA8482C5@hg.openjdk.java.net>

Changeset: 39d15bbb5741
Author:    coffeys
Date:      2013-04-08 23:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/39d15bbb5741

8001032: Restrict object access
Summary: Restrict object access; fix reviewed also by Alexander Fomin
Reviewed-by: alanb, ahgross

! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk
! src/share/classes/com/sun/corba/se/impl/activation/ServerManagerImpl.java
! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java
! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java
! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java
! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBDataParserImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java
- src/share/classes/com/sun/corba/se/impl/orbutil/ORBClassLoader.java
! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java
! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/LocateReplyMessage_1_2.java
! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/MessageBase.java
! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/ReplyMessage_1_0.java
! src/share/classes/com/sun/corba/se/impl/protocol/giopmsgheaders/ReplyMessage_1_1.java
! src/share/classes/com/sun/corba/se/spi/orb/ORB.java
! src/share/classes/com/sun/corba/se/spi/orb/OperationFactory.java
! src/share/classes/sun/corba/JavaCorbaAccess.java

Changeset: 978818df41b9
Author:    chegar
Date:      2013-04-24 10:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/978818df41b9

Merge


Changeset: 68d407e4d204
Author:    chegar
Date:      2013-04-28 08:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/68d407e4d204

Merge


Changeset: 80161c61aa68
Author:    coffeys
Date:      2013-04-30 11:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/80161c61aa68

8000642: Better handling of objects for transportation
Reviewed-by: alanb, mchung, skoivu

! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java
! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java
! src/share/classes/com/sun/corba/se/impl/encoding/IDLJavaSerializationOutputStream.java
! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java
! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java
! src/share/classes/com/sun/corba/se/impl/interceptors/RequestInfoImpl.java
! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java
! src/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java
! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java
! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java
! src/share/classes/com/sun/corba/se/impl/ior/GenericTaggedProfile.java
! src/share/classes/com/sun/corba/se/impl/ior/IORImpl.java
! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java
! src/share/classes/com/sun/corba/se/impl/ior/TaggedComponentFactoryFinderImpl.java
! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java
! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileTemplateImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
! src/share/classes/com/sun/corba/se/impl/orb/ORBSingleton.java
! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/CorbaContactInfoBase.java
! src/share/classes/com/sun/corba/se/impl/transport/SharedCDRContactInfoImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelAcceptorImpl.java
! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java
! src/share/classes/com/sun/corba/se/spi/ior/TaggedComponentBase.java
! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContext.java
! src/share/classes/org/omg/CORBA_2_3/portable/OutputStream.java
+ src/share/classes/sun/corba/OutputStreamFactory.java

Changeset: 4fe1edbec7bc
Author:    chegar
Date:      2013-05-08 10:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/4fe1edbec7bc

Merge


Changeset: e9c924d3475c
Author:    chegar
Date:      2013-05-16 11:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/e9c924d3475c

Merge


Changeset: 216cb38dce0a
Author:    chegar
Date:      2013-05-23 12:41 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/216cb38dce0a

Merge


Changeset: 25e68d232c20
Author:    chegar
Date:      2013-05-31 10:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/25e68d232c20

Merge


Changeset: c1f80e733eb0
Author:    chegar
Date:      2013-06-17 11:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/c1f80e733eb0

Merge

! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java



From chris.hegarty at oracle.com  Tue Jun 18 19:24:16 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:24:16 +0000
Subject: hg: jdk8/tl/jdk: 94 new changesets
Message-ID: <20130618194249.198B5482CE@hg.openjdk.java.net>

Changeset: 3c36782f5129
Author:    bae
Date:      2013-02-27 12:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c36782f5129

8001034: Memory management improvements
Reviewed-by: mschoene, prr, jgodinez

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.h
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c

Changeset: b4a306969af5
Author:    alanb
Date:      2013-02-27 11:44 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4a306969af5

8004288: (fs) Files.probeContentType problems
Reviewed-by: ahgross, sherman

! src/share/classes/java/nio/file/Files.java
! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java

Changeset: ecf85457671a
Author:    dmocek
Date:      2013-03-04 14:34 -0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecf85457671a

8000638: Improve deserialization
Reviewed-by: smarks, hawtin, mchung

! src/share/classes/java/io/ObjectStreamClass.java

Changeset: 1bd2a0bb583e
Author:    jbachorik
Date:      2013-03-07 14:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1bd2a0bb583e

8008603: Improve provision of JMX providers
Reviewed-by: alanb, dfuchs, jfdenise, skoivu

! src/share/classes/javax/management/remote/JMXConnectorFactory.java

Changeset: 711d544b2319
Author:    jbachorik
Date:      2013-03-12 09:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/711d544b2319

8009038: Improve JMX notification support
Summary: Disallowing access to mutable shared arrays
Reviewed-by: dfuchs, mchung, skoivu

! src/share/classes/javax/management/StandardEmitterMBean.java

Changeset: 363547f54176
Author:    jbachorik
Date:      2013-03-12 11:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/363547f54176

8009034: Improve resulting notifications in JMX
Summary: Disallowing access to mutable shared arrays
Reviewed-by: dfuchs, mchung, skoivu

! src/share/classes/javax/management/remote/NotificationResult.java

Changeset: 9114ea4791ec
Author:    jbachorik
Date:      2013-03-14 14:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9114ea4791ec

8008585: Better JMX data handling
Reviewed-by: alanb, dfuchs, jfdenise, skoivu, sjiang

! src/share/classes/javax/management/remote/JMXConnectorFactory.java

Changeset: 200ae4b8f192
Author:    jbachorik
Date:      2013-03-14 14:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/200ae4b8f192

8008607: Better input checking in JMX
Reviewed-by: dfuchs, mchung, skoivu, sjiang

! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java

Changeset: a65111ce1ed7
Author:    khazra
Date:      2013-03-14 13:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a65111ce1ed7

7170730: Improve Windows network stack support.
Summary: Enable exclusive binding of ports on Windows
Reviewed-by: alanb, chegar, ahgross

! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! makefiles/mapfiles/libnio/mapfile-linux
! makefiles/mapfiles/libnio/mapfile-macosx
! makefiles/mapfiles/libnio/mapfile-solaris
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/native/sun/nio/ch/Net.c
! src/windows/classes/java/net/DefaultDatagramSocketImplFactory.java
! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java
! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/classes/java/net/PlainSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/net_util_md.c
! src/windows/native/java/net/net_util_md.h
! src/windows/native/sun/nio/ch/Net.c

Changeset: 30f15138e298
Author:    dmocek
Date:      2013-03-13 17:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30f15138e298

8001033: Refactor network address handling in virtual machine identifiers
Reviewed-by: smarks, hawtin, mchung

! src/share/classes/java/rmi/dgc/VMID.java

Changeset: 9f99c9ab588b
Author:    jgodinez
Date:      2013-03-15 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f99c9ab588b

8007927: Improve cmsAllocProfileSequenceDescription
Reviewed-by: bae, mschoene, prr
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c

Changeset: bf7120252a95
Author:    jbachorik
Date:      2013-03-18 11:17 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf7120252a95

8009996: tests javax/management/mxbean/MiscTest.java and javax/management/mxbean/StandardMBeanOverrideTest.java fail
Reviewed-by: dfuchs, dholmes

! src/share/classes/javax/management/StandardEmitterMBean.java

Changeset: 59ced5cf8344
Author:    dfuchs
Date:      2013-03-18 11:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59ced5cf8344

8001043: Clarify definition restrictions
Reviewed-by: alanb, skoivu, smarks

! src/share/classes/sun/rmi/server/LoaderHandler.java

Changeset: 810688020f65
Author:    sla
Date:      2013-03-19 13:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/810688020f65

8003703: Update RMI connection dialog box
Reviewed-by: skoivu, ahgross, mchung, jbachorik

! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/ProxyClient.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties

Changeset: 8b4c3e09b29a
Author:    jgodinez
Date:      2013-03-19 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4c3e09b29a

8009013: Better handling of T2K glyphs
Reviewed-by: bae, mschoene, prr
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/font/freetypeScaler.c

Changeset: dd60654d4a8b
Author:    darcy
Date:      2013-03-19 14:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd60654d4a8b

8001309: Better handling of annotation interfaces
Reviewed-by: ahgross, smarks, alanb

! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java

Changeset: b412e6128726
Author:    jgodinez
Date:      2013-03-20 10:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b412e6128726

8007929: Improve CurvesAlloc
Reviewed-by: bae, mschoene, prr
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/cmm/lcms/cmsopt.c

Changeset: cfea7f72cbcd
Author:    khazra
Date:      2013-03-20 11:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfea7f72cbcd

8010213: Some api/javax_net/SocketFactory tests fail in 7u25 nightly build
Summary: Eliminate fall-through while setting socket options on Windows
Reviewed-by: alanb, chegar

! src/windows/classes/java/net/DualStackPlainSocketImpl.java

Changeset: 711187756b9e
Author:    leonidr
Date:      2013-03-21 02:13 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/711187756b9e

8004584: Augment applet contextualization
Summary: Do not create the main AppContext for applets
Reviewed-by: art, ahgross

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/awt/SunToolkit.java

Changeset: 9d6d7886a74c
Author:    jbachorik
Date:      2013-03-21 09:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d6d7886a74c

8008623: Better handling of MBeanServers
Reviewed-by: dfuchs, dholmes, skoivu

! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java
! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java

Changeset: 9bcf9c9cb73d
Author:    vinnie
Date:      2013-03-21 12:14 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcf9c9cb73d

8009067: Improve storing keys in KeyStore
Reviewed-by: mullan, skoivu

! src/share/classes/java/security/KeyStore.java

Changeset: 434e0155180c
Author:    jfdenise
Date:      2013-03-26 09:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/434e0155180c

8009004: Better implementation of RMI connections
Summary: Better class handling.
Reviewed-by: alanb, dfuchs, skoivu, jbachorik
Contributed-by: jean-francois.denise at oracle.com

! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java
! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

Changeset: 72fac19dad5c
Author:    sjiang
Date:      2013-03-26 08:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72fac19dad5c

8008615: Improve robustness of JMX internal APIs
Reviewed-by: dfuchs, skoivu, dholmes

! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java
! src/share/classes/javax/management/MBeanServerFactory.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java

Changeset: 27d79fbadda1
Author:    jfdenise
Date:      2013-03-27 09:59 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27d79fbadda1

8008128: Better API coherence for JMX
Summary: Permission for getting classloader
Reviewed-by: alanb, dfuchs, skoivu
Contributed-by: jean-francois.denise at oracle.com

! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java
! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java

Changeset: 311f16954ada
Author:    jbachorik
Date:      2013-03-27 13:29 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/311f16954ada

8010209: Better provision of factories
Reviewed-by: dcubed, ahgross

! src/share/classes/sun/tracing/ProviderSkeleton.java
! src/share/classes/sun/tracing/dtrace/DTraceProvider.java

Changeset: 185cbf454f51
Author:    jgodinez
Date:      2013-03-27 11:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/185cbf454f51

8009654: Improve stability of cmsnamed
Reviewed-by: bae, mschoene, prr
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c

Changeset: c193b7431ea6
Author:    jgodinez
Date:      2013-03-27 15:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c193b7431ea6

8007925: Improve cmsStageAllocLabV2ToV4curves
8007926: Improve cmsPipelineDup
Reviewed-by: bae, mschoene, prr
Contributed-by: jia-hong.chen at oracle.com

! src/share/native/sun/java2d/cmm/lcms/cmslut.c

Changeset: 9137e1efe9fd
Author:    lancea
Date:      2013-03-28 06:55 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9137e1efe9fd

8009554: Improve SerialJavaObject.getFields
Reviewed-by: alanb, skoivu, mchung

! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java

Changeset: 7067e2e493e5
Author:    khazra
Date:      2013-03-28 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7067e2e493e5

8001318: Socket.getLocalAddress not consistent with InetAddress.getLocalHost
Reviewed-by: alanb, chegar, hawtin

! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/sun/net/NetworkClient.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/rmi/server/Activation.java
! src/share/classes/sun/rmi/transport/proxy/WrappedSocket.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java

Changeset: d0ba983c0e70
Author:    jbachorik
Date:      2013-03-28 09:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0ba983c0e70

8008982: Adjust JMX for underlying interface changes
Reviewed-by: mchung, dholmes, dfuchs, skoivu

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java
! src/share/classes/javax/management/JMX.java
! src/share/classes/javax/management/MBeanServerInvocationHandler.java

Changeset: 2db5b7f6aa66
Author:    jgodinez
Date:      2013-03-29 10:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2db5b7f6aa66

8001038: Resourcefully handle resources
Reviewed-by: prr, bae
Contributed-by: jia-hong.chen at oracle.com

! src/share/classes/java/awt/Font.java
! src/share/classes/sun/font/CreatedFontTracker.java

Changeset: d6f0cbba0b8a
Author:    serb
Date:      2013-03-29 22:07 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6f0cbba0b8a

8006328: Improve robustness of sound classes
8009057: Improve MIDI event handling
Reviewed-by: amenkov, art, skoivu

! src/share/classes/com/sun/media/sound/AbstractDataLine.java
! src/share/classes/com/sun/media/sound/AbstractLine.java
! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/AbstractMidiDeviceProvider.java
! src/share/classes/com/sun/media/sound/AbstractMixer.java
! src/share/classes/com/sun/media/sound/AiffFileFormat.java
! src/share/classes/com/sun/media/sound/AiffFileReader.java
! src/share/classes/com/sun/media/sound/AiffFileWriter.java
! src/share/classes/com/sun/media/sound/AlawCodec.java
! src/share/classes/com/sun/media/sound/AuFileFormat.java
! src/share/classes/com/sun/media/sound/AuFileReader.java
! src/share/classes/com/sun/media/sound/AuFileWriter.java
! src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java
! src/share/classes/com/sun/media/sound/AudioFloatConverter.java
! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
! src/share/classes/com/sun/media/sound/AudioFloatInputStream.java
! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java
! src/share/classes/com/sun/media/sound/DLSInfo.java
! src/share/classes/com/sun/media/sound/DLSInstrument.java
! src/share/classes/com/sun/media/sound/DLSModulator.java
! src/share/classes/com/sun/media/sound/DLSRegion.java
! src/share/classes/com/sun/media/sound/DLSSample.java
! src/share/classes/com/sun/media/sound/DLSSampleLoop.java
! src/share/classes/com/sun/media/sound/DLSSampleOptions.java
! src/share/classes/com/sun/media/sound/DLSSoundbank.java
! src/share/classes/com/sun/media/sound/DLSSoundbankReader.java
! src/share/classes/com/sun/media/sound/DataPusher.java
! src/share/classes/com/sun/media/sound/DirectAudioDevice.java
! src/share/classes/com/sun/media/sound/DirectAudioDeviceProvider.java
! src/share/classes/com/sun/media/sound/EmergencySoundbank.java
! src/share/classes/com/sun/media/sound/EventDispatcher.java
! src/share/classes/com/sun/media/sound/FFT.java
! src/share/classes/com/sun/media/sound/FastShortMessage.java
! src/share/classes/com/sun/media/sound/JARSoundbankReader.java
! src/share/classes/com/sun/media/sound/JDK13Services.java
! src/share/classes/com/sun/media/sound/JSSecurityManager.java
! src/share/classes/com/sun/media/sound/JavaSoundAudioClip.java
! src/share/classes/com/sun/media/sound/MidiDeviceReceiverEnvelope.java
! src/share/classes/com/sun/media/sound/MidiDeviceTransmitterEnvelope.java
! src/share/classes/com/sun/media/sound/MidiInDevice.java
! src/share/classes/com/sun/media/sound/MidiInDeviceProvider.java
! src/share/classes/com/sun/media/sound/MidiOutDevice.java
! src/share/classes/com/sun/media/sound/MidiOutDeviceProvider.java
! src/share/classes/com/sun/media/sound/MidiUtils.java
! src/share/classes/com/sun/media/sound/ModelByteBuffer.java
! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
! src/share/classes/com/sun/media/sound/ModelConnectionBlock.java
! src/share/classes/com/sun/media/sound/ModelDestination.java
! src/share/classes/com/sun/media/sound/ModelIdentifier.java
! src/share/classes/com/sun/media/sound/ModelInstrument.java
! src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java
! src/share/classes/com/sun/media/sound/ModelMappedInstrument.java
! src/share/classes/com/sun/media/sound/ModelPatch.java
! src/share/classes/com/sun/media/sound/ModelPerformer.java
! src/share/classes/com/sun/media/sound/ModelSource.java
! src/share/classes/com/sun/media/sound/ModelStandardDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java
! src/share/classes/com/sun/media/sound/ModelStandardTransform.java
! src/share/classes/com/sun/media/sound/PCMtoPCMCodec.java
! src/share/classes/com/sun/media/sound/Platform.java
! src/share/classes/com/sun/media/sound/PortMixer.java
! src/share/classes/com/sun/media/sound/PortMixerProvider.java
! src/share/classes/com/sun/media/sound/Printer.java
! src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java
! src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java
! src/share/classes/com/sun/media/sound/RIFFReader.java
! src/share/classes/com/sun/media/sound/RIFFWriter.java
! src/share/classes/com/sun/media/sound/RealTimeSequencer.java
! src/share/classes/com/sun/media/sound/RealTimeSequencerProvider.java
! src/share/classes/com/sun/media/sound/SF2GlobalRegion.java
! src/share/classes/com/sun/media/sound/SF2Instrument.java
! src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java
! src/share/classes/com/sun/media/sound/SF2Layer.java
! src/share/classes/com/sun/media/sound/SF2LayerRegion.java
! src/share/classes/com/sun/media/sound/SF2Modulator.java
! src/share/classes/com/sun/media/sound/SF2Sample.java
! src/share/classes/com/sun/media/sound/SF2Soundbank.java
! src/share/classes/com/sun/media/sound/SF2SoundbankReader.java
! src/share/classes/com/sun/media/sound/SoftAbstractResampler.java
! src/share/classes/com/sun/media/sound/SoftAudioBuffer.java
! src/share/classes/com/sun/media/sound/SoftAudioPusher.java
! src/share/classes/com/sun/media/sound/SoftChannel.java
! src/share/classes/com/sun/media/sound/SoftChannelProxy.java
! src/share/classes/com/sun/media/sound/SoftChorus.java
! src/share/classes/com/sun/media/sound/SoftCubicResampler.java
! src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java
! src/share/classes/com/sun/media/sound/SoftFilter.java
! src/share/classes/com/sun/media/sound/SoftInstrument.java
! src/share/classes/com/sun/media/sound/SoftJitterCorrector.java
! src/share/classes/com/sun/media/sound/SoftLanczosResampler.java
! src/share/classes/com/sun/media/sound/SoftLimiter.java
! src/share/classes/com/sun/media/sound/SoftLinearResampler.java
! src/share/classes/com/sun/media/sound/SoftLinearResampler2.java
! src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java
! src/share/classes/com/sun/media/sound/SoftMainMixer.java
! src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
! src/share/classes/com/sun/media/sound/SoftMixingClip.java
! src/share/classes/com/sun/media/sound/SoftMixingDataLine.java
! src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java
! src/share/classes/com/sun/media/sound/SoftMixingMixer.java
! src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java
! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
! src/share/classes/com/sun/media/sound/SoftPerformer.java
! src/share/classes/com/sun/media/sound/SoftPointResampler.java
! src/share/classes/com/sun/media/sound/SoftProvider.java
! src/share/classes/com/sun/media/sound/SoftReceiver.java
! src/share/classes/com/sun/media/sound/SoftReverb.java
! src/share/classes/com/sun/media/sound/SoftShortMessage.java
! src/share/classes/com/sun/media/sound/SoftSincResampler.java
! src/share/classes/com/sun/media/sound/SoftSynthesizer.java
! src/share/classes/com/sun/media/sound/SoftTuning.java
! src/share/classes/com/sun/media/sound/SoftVoice.java
! src/share/classes/com/sun/media/sound/StandardMidiFileReader.java
! src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java
! src/share/classes/com/sun/media/sound/SunCodec.java
! src/share/classes/com/sun/media/sound/SunFileReader.java
! src/share/classes/com/sun/media/sound/SunFileWriter.java
! src/share/classes/com/sun/media/sound/Toolkit.java
! src/share/classes/com/sun/media/sound/UlawCodec.java
! src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
! src/share/classes/com/sun/media/sound/WaveFileFormat.java
! src/share/classes/com/sun/media/sound/WaveFileReader.java
! src/share/classes/com/sun/media/sound/WaveFileWriter.java
! src/share/classes/com/sun/media/sound/WaveFloatFileReader.java
! src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java
! src/share/classes/javax/sound/midi/MetaMessage.java
! src/share/classes/javax/sound/sampled/Mixer.java
! src/share/classes/sun/audio/AudioData.java
! src/share/classes/sun/audio/AudioDataStream.java
! src/share/classes/sun/audio/AudioDevice.java
! src/share/classes/sun/audio/AudioPlayer.java
! src/share/classes/sun/audio/AudioStream.java
! src/share/classes/sun/audio/AudioStreamSequence.java
! src/share/classes/sun/audio/AudioTranslatorStream.java
! src/share/classes/sun/audio/ContinuousAudioDataStream.java
! src/share/classes/sun/audio/InvalidAudioFormatException.java

Changeset: 2eac60e99307
Author:    dsamersoff
Date:      2013-03-31 22:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eac60e99307

8007471: Improve MBean notifications
Summary: Improve MBean notifications
Reviewed-by: dfuchs, mchung, alanb, skoivu

! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java
! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java

Changeset: 107f21efda78
Author:    dsamersoff
Date:      2013-03-31 22:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/107f21efda78

8008120: Improve JMX class checking
Summary: Improve JMX class checking
Reviewed-by: mchung, dfuchs, alanb, skoivu

! src/share/classes/javax/management/relation/RelationNotification.java

Changeset: 0bddd4e8bfb6
Author:    dsamersoff
Date:      2013-03-31 23:47 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bddd4e8bfb6

8008124: Better compliance testing
Summary: Better compliance testing
Reviewed-by: dfuchs, jfdenise, skoivu, alanb

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java

Changeset: 0d36b1e3e509
Author:    prr
Date:      2013-04-01 09:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d36b1e3e509

8005007: Better glyph processing
Reviewed-by: srl, mschoene, bae

! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/native/sun/font/layout/LEGlyphStorage.cpp
! src/share/native/sun/font/layout/LookupProcessor.cpp

Changeset: 4224b02452f5
Author:    sjiang
Date:      2013-04-02 10:38 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4224b02452f5

8007467: Better JMX type conversion
Reviewed-by: dfuchs, mchung, skoivu

! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java
! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java
! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanIntrospector.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java

Changeset: 5ae5c4120014
Author:    egahlin
Date:      2013-03-21 13:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ae5c4120014

8008611: Better handling of annotations in JMX
Reviewed-by: skoivu, dholmes, jfdenise

! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java

Changeset: 802f5e480c8a
Author:    mullan
Date:      2013-04-05 10:17 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/802f5e480c8a

8001330: Improve on checking order
Reviewed-by: acorn, hawtin

! src/share/classes/java/security/AccessControlContext.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/security/ProtectionDomain.java

Changeset: e5969bf37f26
Author:    chegar
Date:      2013-04-08 06:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5969bf37f26

8008593: Better URLClassLoader resource management
Reviewed-by: alanb, sherman, hawtin

! make/java/zip/mapfile-vers
! make/java/zip/reorder-i586
! make/java/zip/reorder-sparc
! make/java/zip/reorder-sparcv9
! makefiles/mapfiles/libzip/mapfile-vers
! makefiles/mapfiles/libzip/reorder-sparc
! makefiles/mapfiles/libzip/reorder-sparcv9
! makefiles/mapfiles/libzip/reorder-x86
! src/share/classes/java/util/zip/ZipFile.java
+ src/share/classes/sun/misc/JavaUtilZipFileAccess.java
! src/share/classes/sun/misc/SharedSecrets.java
! src/share/classes/sun/misc/URLClassPath.java
! src/share/native/java/util/zip/ZipFile.c
! src/share/native/java/util/zip/zip_util.c
! src/share/native/java/util/zip/zip_util.h

Changeset: 6f75b365af19
Author:    vinnie
Date:      2013-04-08 21:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f75b365af19

8009235: Improve handling of TSA data
Reviewed-by: ahgross, mullan

! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/timestamp/TimestampToken.java

Changeset: 5496abfc666a
Author:    prr
Date:      2013-04-08 13:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5496abfc666a

8011248: Better Component Rasters
Reviewed-by: bae, vadim, mschoene

! src/share/classes/sun/awt/image/IntegerComponentRaster.java

Changeset: 761e0002dcfe
Author:    prr
Date:      2013-04-08 13:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/761e0002dcfe

8011253: Better Short Component Rasters
Reviewed-by: bae, vadim, mschoene

! src/share/classes/sun/awt/image/ShortBandedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java

Changeset: 1adc1051f2d3
Author:    prr
Date:      2013-04-08 13:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1adc1051f2d3

8011257: Better Byte Component Rasters
Reviewed-by: bae, vadim, mschoene

! src/share/classes/sun/awt/image/ByteBandedRaster.java
! src/share/classes/sun/awt/image/ByteComponentRaster.java

Changeset: eafd52d53f09
Author:    bae
Date:      2013-04-10 15:55 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eafd52d53f09

8011243: Improve ImagingLib
Reviewed-by: prr, vadim

! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c

Changeset: fa42f0831e66
Author:    bae
Date:      2013-04-12 14:08 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fa42f0831e66

8011992: java/awt/image/mlib/MlibOpsTest.java failed since jdk7u25b05
Reviewed-by: vadim

! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! test/java/awt/image/mlib/MlibOpsTest.java

Changeset: bfe04328d394
Author:    bae
Date:      2013-04-15 14:11 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfe04328d394

8012112: java/awt/image/mlib/MlibOpsTest.java fails on sparc solaris
Reviewed-by: prr, vadim

! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! test/java/awt/image/mlib/MlibOpsTest.java

Changeset: 7d90e3e0a8ec
Author:    leonidr
Date:      2013-04-16 21:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d90e3e0a8ec

8011695: [tck-red] Application can not be run, the Security Warning dialog is gray.
Summary: EventQueue shouldn't use AppContext.getAppContext() to obtain its AppContext.
Reviewed-by: art

! src/share/classes/java/awt/EventQueue.java
! src/share/classes/javax/swing/RepaintManager.java
! src/share/classes/sun/awt/SunToolkit.java

Changeset: cf14f699f36c
Author:    anthony
Date:      2013-04-18 13:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf14f699f36c

8009071: Improve shape handling
Reviewed-by: art, mschoene

! src/macosx/native/sun/awt/CRobot.m
! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
+ src/share/native/common/sizecalc.h
! src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c
! src/share/native/sun/awt/splashscreen/splashscreen_gif.c
! src/share/native/sun/java2d/pipe/Region.c
! src/solaris/native/sun/awt/awt_Robot.c
! src/solaris/native/sun/awt/awt_UNIXToolkit.c
! src/solaris/native/sun/awt/fontpath.c
! src/solaris/native/sun/awt/gtk2_interface.c
! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c
! src/solaris/native/sun/xawt/XlibWrapper.c
! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c
! src/windows/native/sun/font/lcdglyph.c
! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
! src/windows/native/sun/java2d/windows/GDIRenderer.cpp
! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp
! src/windows/native/sun/windows/CmdIDList.cpp
! src/windows/native/sun/windows/Devices.cpp
! src/windows/native/sun/windows/ShellFolder2.cpp
! src/windows/native/sun/windows/WPrinterJob.cpp
! src/windows/native/sun/windows/alloc.h
! src/windows/native/sun/windows/awt.h
! src/windows/native/sun/windows/awt_BitmapUtil.cpp
! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Cursor.cpp
! src/windows/native/sun/windows/awt_DataTransferer.cpp
! src/windows/native/sun/windows/awt_DesktopProperties.cpp
! src/windows/native/sun/windows/awt_DnDDT.cpp
! src/windows/native/sun/windows/awt_InputMethod.cpp
! src/windows/native/sun/windows/awt_PrintControl.cpp
! src/windows/native/sun/windows/awt_PrintJob.cpp
! src/windows/native/sun/windows/awt_Robot.cpp

Changeset: 4934254492af
Author:    sundar
Date:      2013-04-19 11:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4934254492af

8006611: Improve scripting
Reviewed-by: mchung

! src/share/classes/javax/script/ScriptEngineManager.java

Changeset: a73ecb5085eb
Author:    jfranck
Date:      2013-04-19 14:40 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a73ecb5085eb

8007812: (reflect) Class.getEnclosingMethod problematic for some classes
Summary: Better checking in getEnclosing(Method|Constructor|Class)
Reviewed-by: darcy, ahgross, mchung

! src/share/classes/java/lang/Class.java
+ test/lib/testlibrary/ClassFileInstaller.java

Changeset: 15370008c68d
Author:    chegar
Date:      2013-04-22 10:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15370008c68d

8012692: SerialJavaObject.java should be CallerSensitive aware
Reviewed-by: mchung

! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java

Changeset: ff3ac3680ffa
Author:    mchung
Date:      2013-04-22 10:22 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff3ac3680ffa

8012689: CallerSensitive annotation should not have CONSTRUCTOR Target
Reviewed-by: chegar

! src/share/classes/sun/reflect/CallerSensitive.java

Changeset: 783ed53bce0b
Author:    smarks
Date:      2013-04-22 10:55 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/783ed53bce0b

8008132: Better serialization support
Reviewed-by: alanb, hawtin

! src/share/classes/java/io/ObjectOutputStream.java
! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/io/ObjectStreamField.java

Changeset: bb0ec4661eb8
Author:    chegar
Date:      2013-04-22 11:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb0ec4661eb8

8012917: ObjectStreamClass and ObjectStreamField should be CallerSensitive aware
Reviewed-by: mchung

! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/io/ObjectStreamField.java

Changeset: 10558009e439
Author:    anthony
Date:      2013-04-09 12:05 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10558009e439

8011154: java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java failed since 7u25b03 on windows
Reviewed-by: art, yan

! src/windows/native/sun/windows/awt_Component.cpp

Changeset: 0f0ff6e9da05
Author:    mullan
Date:      2013-04-22 11:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f0ff6e9da05

6741606: Integrate Apache Santuario
Reviewed-by: vinnie, hawtin

! 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/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/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/implementations/RetrievalMethodResolver.java
! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.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/Transforms.java
! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.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/utils/ClassLoaderUtils.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/I18n.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/ResolverFragment.java
! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java
! src/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/javax/xml/crypto/dsig/GenerationTests.java
! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java
! test/javax/xml/crypto/dsig/ValidationTests.java

Changeset: 72f55e763113
Author:    leonidr
Date:      2013-03-27 16:37 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72f55e763113

8003559: Update display of applet windows
Summary: Implemented applet security warning for OS X port
Reviewed-by: art, anthony, serb, skoivu

! make/sun/awt/Makefile
+ make/sun/awt/ToBin.java
! make/sun/lwawt/FILES_export_macosx.gmk
! make/sun/xawt/Makefile
- make/sun/xawt/ToBin.java
! makefiles/GenerateJavaSources.gmk
! makefiles/GensrcIcons.gmk
! makefiles/Tools.gmk
+ makefiles/sun/awt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
+ src/macosx/classes/sun/lwawt/PlatformEventNotifier.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
+ src/macosx/classes/sun/lwawt/SecurityWarningWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java
+ src/macosx/classes/sun/lwawt/macosx/CWarningWindow.java
! src/macosx/classes/sun/lwawt/macosx/CWrapper.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/CWrapper.m
+ src/share/classes/sun/awt/IconInfo.java
+ src/share/classes/sun/awt/resources/security-icon-bw16.png
+ src/share/classes/sun/awt/resources/security-icon-bw24.png
+ src/share/classes/sun/awt/resources/security-icon-bw32.png
+ src/share/classes/sun/awt/resources/security-icon-bw48.png
+ src/share/classes/sun/awt/resources/security-icon-interim16.png
+ src/share/classes/sun/awt/resources/security-icon-interim24.png
+ src/share/classes/sun/awt/resources/security-icon-interim32.png
+ src/share/classes/sun/awt/resources/security-icon-interim48.png
+ src/share/classes/sun/awt/resources/security-icon-yellow16.png
+ src/share/classes/sun/awt/resources/security-icon-yellow24.png
+ src/share/classes/sun/awt/resources/security-icon-yellow32.png
+ src/share/classes/sun/awt/resources/security-icon-yellow48.png
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWarningWindow.java
! src/solaris/classes/sun/awt/X11/XWindowAttributesData.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png

Changeset: 31980806a21a
Author:    chegar
Date:      2013-04-19 14:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31980806a21a

Merge

- make/sun/xawt/ToBin.java
! makefiles/Tools.gmk
- makefiles/sun/awt/X11/ToBin.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png

Changeset: 7615af456906
Author:    chegar
Date:      2013-04-22 11:29 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7615af456906

Merge


Changeset: d0dbbdbb217f
Author:    mchung
Date:      2013-04-17 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0dbbdbb217f

8011557: Improve reflection utility classes
Reviewed-by: ahgross, alanb

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/sun/reflect/misc/ReflectUtil.java

Changeset: 25b69fbfe80f
Author:    chegar
Date:      2013-04-23 11:13 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25b69fbfe80f

Merge

! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/sun/security/timestamp/TimestampToken.java

Changeset: 3197c702c8d1
Author:    bae
Date:      2013-04-24 21:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3197c702c8d1

8012438: Better image validation
Reviewed-by: prr

! src/share/classes/java/awt/image/ComponentSampleModel.java
! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java
! src/share/classes/java/awt/image/Raster.java
! src/share/classes/sun/awt/image/ByteBandedRaster.java
! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/ShortBandedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/native/sun/awt/medialib/awt_ImagingLib.c

Changeset: 256ebcf1317b
Author:    chegar
Date:      2013-04-28 09:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/256ebcf1317b

Merge

! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/sun/awt/SunToolkit.java
- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java

Changeset: c3a08adee3ea
Author:    chegar
Date:      2013-05-01 12:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3a08adee3ea

Merge


Changeset: f1c0e2da008c
Author:    chegar
Date:      2013-05-08 11:22 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1c0e2da008c

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
- src/share/classes/java/beans/ReflectionUtils.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/nio/file/Files.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java
- test/java/io/Serializable/accessConstants/AccessConstants.java
- test/java/nio/file/Files/walkFileTree/walk_file_tree.sh
- test/sun/reflect/CallerSensitive/MethodFinder.java

Changeset: b8102c2f6632
Author:    chegar
Date:      2013-05-16 11:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8102c2f6632

Merge


Changeset: 60a2184a71f2
Author:    chegar
Date:      2013-05-23 12:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60a2184a71f2

Merge

- make/com/sun/script/Makefile
- make/sun/org/Makefile
- make/sun/org/mozilla/Makefile
- make/sun/org/mozilla/javascript/Makefile
! src/macosx/classes/sun/lwawt/LWToolkit.java
- src/share/classes/com/sun/script/javascript/ExternalScriptable.java
- src/share/classes/com/sun/script/javascript/JSAdapter.java
- src/share/classes/com/sun/script/javascript/JavaAdapter.java
- src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory
- src/share/classes/com/sun/script/javascript/RhinoClassShutter.java
- src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java
- src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java
- src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java
- src/share/classes/com/sun/script/javascript/RhinoTopLevel.java
- src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java
- src/share/classes/com/sun/script/util/BindingsBase.java
- src/share/classes/com/sun/script/util/BindingsEntrySet.java
- src/share/classes/com/sun/script/util/BindingsImpl.java
- src/share/classes/com/sun/script/util/InterfaceImplementor.java
- src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
- src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/zip/ZipFile.java
! src/share/classes/sun/net/httpserver/ServerImpl.java
- src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider
- test/java/lang/Thread/StackTraces.java
- test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
- test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
- test/java/util/logging/bundlesearch/LoadItUp.java
- test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java
- test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java
- test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java

Changeset: aa559d55fc4a
Author:    chegar
Date:      2013-05-31 10:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa559d55fc4a

Merge


Changeset: 405cd7338069
Author:    chegar
Date:      2013-06-10 10:38 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/405cd7338069

Merge

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/security/AccessControlContext.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/util/zip/ZipFile.java
- src/share/classes/sun/misc/FDBigInt.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! src/share/native/sun/java2d/cmm/lcms/cmslut.c
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_GraphicsEnv.h
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c
! src/solaris/native/sun/xawt/XlibWrapper.c
! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
- test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

Changeset: cd0140e5bee5
Author:    prr
Date:      2013-04-25 16:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd0140e5bee5

8012421: Better positioning of PairPositioning
Reviewed-by: srl, mschoene, vadim

! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.h

Changeset: 97149218a8ad
Author:    bae
Date:      2013-04-26 11:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97149218a8ad

8012601: Better validation of image layouts
Reviewed-by: prr

! src/share/classes/java/awt/image/BufferedImage.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java

Changeset: 40c65c6711ee
Author:    prr
Date:      2013-04-26 15:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40c65c6711ee

8012617: ArrayIndexOutOfBoundsException with some fonts using LineBreakMeasurer
Reviewed-by: bae, srl

! src/share/classes/sun/font/ExtendedTextSourceLabel.java
! src/share/classes/sun/font/GlyphLayout.java
! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp
! src/share/native/sun/font/layout/ExtensionSubtables.cpp
! src/share/native/sun/font/layout/ExtensionSubtables.h
! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp
! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp
! src/share/native/sun/font/layout/SunLayoutEngine.cpp
+ test/java/awt/font/LineBreakMeasurer/AllFontsLBM.java

Changeset: 30c8c83eeb70
Author:    mullan
Date:      2013-04-29 11:47 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30c8c83eeb70

8009217: REGRESSION: test com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java fails to compile since 7u21b03
Reviewed-by: xuelei

! test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java
! test/com/sun/org/apache/xml/internal/security/transforms/MyTransform.java

Changeset: 19af6fae7b98
Author:    bae
Date:      2013-04-30 04:41 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19af6fae7b98

8012597: Better image channel verification
Reviewed-by: vadim

! src/share/classes/java/awt/image/BufferedImage.java
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/medialib/awt_ImagingLib.c

Changeset: 1b86ce92dc2f
Author:    alexsch
Date:      2013-04-30 13:55 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b86ce92dc2f

8012330: [macosx] Sometimes the applet showing the modal dialog itself loses the ability to gain focus
Reviewed-by: serb, ant

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java

Changeset: d4c5b2792d55
Author:    dfuchs
Date:      2013-05-02 10:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4c5b2792d55

8012243: about 30% regression on specjvm2008.serial on 7u25 comparing 7u21
Reviewed-by: alanb, skoivu, smarks, mchung

! src/share/classes/java/io/ObjectStreamClass.java
! src/share/classes/java/io/ObjectStreamField.java

Changeset: e898a9e1404b
Author:    mullan
Date:      2013-05-02 11:42 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e898a9e1404b

8008744: Rework part of fix for JDK-6741606
Reviewed-by: xuelei, ahgross

+ src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/ClassLoaderUtils.java
! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java
+ src/share/classes/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderUtils.java
! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java
- src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java

Changeset: b3850bdca7f1
Author:    leonidr
Date:      2013-05-06 16:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3850bdca7f1

8012933: Test closed/java/awt/Dialog/DialogAnotherThread/JaWSTest.java fails since jdk 7u25 b07
Summary: Do not mark context as disposed until we've posted all the events
Reviewed-by: art

! src/share/classes/sun/awt/AppContext.java
+ test/sun/awt/AppContext/8012933/Test8012933.java

Changeset: fb7dc7c54145
Author:    jfranck
Date:      2013-05-07 13:23 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb7dc7c54145

8011139: (reflect) Revise checking in getEnclosingClass
Reviewed-by: darcy, mchung, ahgross

! src/share/classes/java/lang/Class.java

Changeset: cefd77938a6c
Author:    twisti
Date:      2013-05-08 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cefd77938a6c

8009424: Restrict publicLookup with additional checks
Reviewed-by: vlivanov, jdn

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 7f2fc413fb1d
Author:    coffeys
Date:      2013-05-09 20:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f2fc413fb1d

8013196: TimeZone.getDefault() throws NPE due to sun.awt.AppContext.getAppContext()
Reviewed-by: mchung, okutsu

! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/misc/SharedSecrets.java

Changeset: 3948bdc62c34
Author:    mullan
Date:      2013-05-13 17:50 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3948bdc62c34

8010714: XML DSig API allows a RetrievalMethod to reference another RetrievalMethod
Reviewed-by: xuelei, hawtin

! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.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/ObjectContainer.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/SignatureProperties.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java
! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java
! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java
! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java
! test/com/sun/org/apache/xml/internal/security/TruncateHMAC.java

Changeset: 5d342b420db0
Author:    xuelei
Date:      2013-05-14 05:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d342b420db0

8014281: Better checking of XML signature
Summary: also reviewed by Andrew Gross and Christophe Ravel
Reviewed-by: mullan

! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java

Changeset: c261596407b5
Author:    bae
Date:      2013-05-14 21:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c261596407b5

8014427: REGRESSION: closed/javax/imageio/plugins/bmp/Write3ByteBgrTest.java fails since 7u25 b09
Reviewed-by: prr

! src/share/classes/java/awt/image/Raster.java

Changeset: 392f03789497
Author:    mchung
Date:      2013-05-14 08:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/392f03789497

8010727: WLS fails to add a logger with "" in its own LogManager subclass instance
Reviewed-by: alanb, jgish

! src/share/classes/java/util/logging/LogManager.java
+ test/java/util/logging/LogManagerInstanceTest.java

Changeset: 8e07710dca9a
Author:    bae
Date:      2013-05-17 16:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e07710dca9a

8014205: Most of the Swing dialogs are blank on one win7 MUI
Reviewed-by: vadim

! src/share/classes/java/awt/image/BufferedImage.java

Changeset: 1d8fe72d3c4e
Author:    leonidr
Date:      2013-05-20 19:07 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d8fe72d3c4e

8014718: Netbeans IDE begins to throw a lot exceptions since 7u25 b10
Summary: Removed logging from SunToolkit
Reviewed-by: art

! src/share/classes/java/awt/Toolkit.java
! src/share/classes/sun/awt/SunToolkit.java

Changeset: 25baf6dc46a0
Author:    chegar
Date:      2013-05-22 13:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25baf6dc46a0

8014737: java/lang/invoke/7196190/MHProxyTest.java fails after 8009424
Reviewed-by: twisti

- test/java/lang/invoke/7196190/MHProxyTest.java

Changeset: a4ea4234facf
Author:    chegar
Date:      2013-06-14 16:38 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4ea4234facf

8012156: tools/javac/file/zip/T6865530.java fails for win32/64 in 7u25 nightly runs
Reviewed-by: alanb

! src/share/classes/sun/misc/URLClassPath.java

Changeset: 7d56b8a92f52
Author:    chegar
Date:      2013-06-17 11:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d56b8a92f52

Merge

! make/sun/awt/Makefile
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/macosx/native/sun/awt/LWCToolkit.m
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/net/ServerSocket.java
! src/share/classes/java/net/Socket.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/java/security/KeyStore.java
- src/share/classes/sun/misc/Hashing.java
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
! src/solaris/native/sun/xawt/XlibWrapper.c
- test/sun/misc/Hashing.java

Changeset: e3b075b8f21f
Author:    chegar
Date:      2013-06-17 14:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3b075b8f21f

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/net/ftp/impl/FtpClient.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java

Changeset: c31fa946605c
Author:    chegar
Date:      2013-06-18 09:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c31fa946605c

Merge

! src/share/classes/java/lang/Class.java

Changeset: 403e63195af5
Author:    chegar
Date:      2013-06-18 16:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/403e63195af5

Merge




From chris.hegarty at oracle.com  Tue Jun 18 19:52:58 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:52:58 +0000
Subject: hg: jdk8/tl/nashorn: 9 new changesets
Message-ID: <20130618195304.A3AE0482D1@hg.openjdk.java.net>

Changeset: af8a98ea83d4
Author:    chegar
Date:      2013-04-24 11:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/af8a98ea83d4

Merge


Changeset: 2237e2ff3685
Author:    chegar
Date:      2013-04-28 08:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2237e2ff3685

Merge


Changeset: 2a377892c255
Author:    chegar
Date:      2013-05-08 10:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2a377892c255

Merge


Changeset: d8ae3d87ca26
Author:    chegar
Date:      2013-05-16 11:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d8ae3d87ca26

Merge


Changeset: d3076aecc567
Author:    chegar
Date:      2013-05-23 12:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d3076aecc567

Merge

- src/jdk/nashorn/internal/ir/LineNumberNode.java
- src/jdk/nashorn/internal/ir/Location.java
- src/jdk/nashorn/internal/runtime/SpillProperty.java
- test/script/trusted/logcoverage.js

Changeset: ded7168cb008
Author:    chegar
Date:      2013-05-31 10:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ded7168cb008

Merge


Changeset: 2b61f82350de
Author:    chegar
Date:      2013-06-10 09:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2b61f82350de

Merge

- src/jdk/nashorn/internal/objects/DateParser.java
- src/jdk/nashorn/internal/runtime/options/ValueOption.java
- src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java
- src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java
- src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java
- src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java
- src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java
- src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java
- src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java
- src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java
- src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java
- src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java
- src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java
- src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java
- src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java
- src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java
- src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java
- src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java
- src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java
- src/netscape/javascript/JSObject.java

Changeset: 12f1d8d74375
Author:    chegar
Date:      2013-06-17 11:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/12f1d8d74375

Merge


Changeset: fbcd5c26937a
Author:    chegar
Date:      2013-06-18 16:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fbcd5c26937a

Merge




From chris.hegarty at oracle.com  Tue Jun 18 19:52:03 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 18 Jun 2013 19:52:03 +0000
Subject: hg: jdk8/tl/langtools: 14 new changesets
Message-ID: <20130618195241.905BE482CF@hg.openjdk.java.net>

Changeset: 4d4818b6df72
Author:    chegar
Date:      2013-04-24 11:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4d4818b6df72

Merge


Changeset: 27cda5134748
Author:    chegar
Date:      2013-04-28 08:16 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27cda5134748

Merge


Changeset: c7c6bfe7fc1f
Author:    bpatel
Date:      2013-05-03 08:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7c6bfe7fc1f

8012375: Improve Javadoc framing
Reviewed-by: mduigou, jlaskey

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java

Changeset: 8074ccd57d89
Author:    chegar
Date:      2013-05-08 10:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8074ccd57d89

Merge


Changeset: 9d7d36e6927c
Author:    chegar
Date:      2013-05-08 10:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d7d36e6927c

Merge


Changeset: 7ee1fd365cdd
Author:    chegar
Date:      2013-05-16 11:42 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7ee1fd365cdd

Merge


Changeset: f1b90ea7d402
Author:    chegar
Date:      2013-05-23 12:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f1b90ea7d402

Merge

- src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java
- src/share/classes/javax/tools/annotation/GenerateNativeHeader.java
- test/tools/javac/nativeHeaders/javahComparison/TestClass2.java
- test/tools/javac/nativeHeaders/javahComparison/TestClass3.java

Changeset: 76d08c649607
Author:    chegar
Date:      2013-05-31 10:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76d08c649607

Merge


Changeset: 536cad596942
Author:    bpatel
Date:      2013-06-07 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/536cad596942

8015997: Additional improvement in Javadoc framing
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java

Changeset: da8d0ee0938e
Author:    chegar
Date:      2013-06-10 09:52 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/da8d0ee0938e

Merge

- test/tools/javac/HiddenAbstractMethod/Test
- test/tools/javac/NonAmbiguousField/Test

Changeset: cc89c8333127
Author:    chegar
Date:      2013-06-11 09:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc89c8333127

Merge


Changeset: 31e1151ef3cc
Author:    chegar
Date:      2013-06-17 11:27 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31e1151ef3cc

Merge


Changeset: db6bf740a578
Author:    chegar
Date:      2013-06-18 09:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db6bf740a578

Merge


Changeset: 64f511787fd9
Author:    chegar
Date:      2013-06-18 20:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64f511787fd9

Merge




From thomas.schatzl at oracle.com  Tue Jun 18 21:08:43 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 18 Jun 2013 23:08:43 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries than
	expected
Message-ID: <1371589723.2524.43.camel@cirrus>

Hi all,

  can I have reviews for the following change?

It happens if multiple threads are enqueuing and dequeuing reference
objects into a reference queue, that Reference objects may be enqueued
at multiple times.

This is because when java.lang.ref.ReferenceQueue.poll() returns and
inactivates a Reference object, another thread may just be during
enqueuing it again.

In the test case provided, the two threads that conflict are the
reference handler thread and the program (main) thread.

Relevant code:

ReferenceHandlerThread.run():

0: [...]
1: ReferenceQueue q = r.queue; // r is the reference
2: if (r != ReferenceQueue.NULL)
3:   q.enqueue().

ReferenceQueue::poll()(reallyPoll()) code (I removed lots of code here)

1: synchronized(lock) {
2:   [...]
3:   r.queue = ReferenceQueue.NULL;
3:}

I.e. while ReferenceQueue.poll() sets the Reference's queue to the NULL
queue so that that reference will not be enqueued again (or at most into
the NULL queue which is a nop), it happens that if the task switch
occurs between lines 2 and 3 of the reference handler thread, q still
contains the old queue reference, and the reference handler thread will
enqueue the Reference into the original queue again.

You can achieve the same effect by simply calling
ReferenceQueue.enqueue() (i.e. without the reference handler thread, or
within the reference handler thread doing the != NULL check), it's just
that in such a case the "old" ReferenceQueue is stored in some register.

The guard for ReferenceQueue.NULL does not have any effect except for
possibly saving the virtual call. Simply calling r.enqueue() exhibits
the same problem.

The proposed solution is to filter out References within
ReferenceQueue.enqueue() again. At that point we can check whether the
given Reference is actually meant for this queue or not. Already removed
References are known to be "inactive" (as enqueue and poll are mutually
exclusive using a lock), in particular the References' queue is
different (actually the NULL queue) to the queue it is being enqueued.

This change should pose no change in semantics, as the ReferenceQueue of
the Reference can only be set in its constructor, and as soon as the
Reference is removed from a ReferenceQueue, its ReferenceQueue will be
the NULL queue. (I.e. before this change you could not enqueue such an
"inactive" Reference multiple times anyway)

(too many References and queues here :)

Webrev with test case
http://cr.openjdk.java.net/~tschatzl/8014890/webrev/

JIRA:
https://jbs.oracle.com/bugs/browse/JDK-8014890

bugs.sun.com
http://bugs.sun.com/view_bug.do?bug_id=8014890

Testing:
jck, jprt, manual testing

Note that I also need a sponsor to push in case this change is approved.

Thanks,
  Thomas



From mike.duigou at oracle.com  Tue Jun 18 21:12:03 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 18 Jun 2013 21:12:03 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130618211227.83556482D7@hg.openjdk.java.net>

Changeset: ba544aab1fcd
Author:    bpb
Date:      2013-06-18 11:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba544aab1fcd

8015395: NumberFormatException during startup if JDK-internal property java.lang.Integer.IntegerCache.high set to bad value
Summary: Fall back to default if a bad value is passed for this property.
Reviewed-by: mduigou

! src/share/classes/java/lang/Integer.java

Changeset: eb1a3c50a2a9
Author:    mduigou
Date:      2013-06-18 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb1a3c50a2a9

Merge




From martinrb at google.com  Tue Jun 18 22:14:09 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Jun 2013 15:14:09 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: <277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
Message-ID: 

Thanks for reusing the existing testing infrastructure I wrote many years
ago.

---
I'm a big fan of diversity in testing, and so I much prefer using a
different random seed every time to the "reliability" of deterministic
tests.  I you wanted to add repeatability support, you could easily have
the test save the initial seed and provide it in case of failure.


-    static final Random rnd = new Random();+    static final Random
rnd = new Random(8675309);


---
I don't like the removal of tests below.  Can we find some other way of
handling this (perhaps by catching NotSerializableException, as I did in
MOAT.java?)
                    if (! (xxx.getCause() instanceof
NotSerializableException))

-        if (maybe(4) && s instanceof Serializable)-
equal2(s, serialClone(s));+// mduigou: I had to comment this out for
the Collection wrappers which wrap+// unserializable sets.+//
if (maybe(4) && s instanceof Serializable)+//            equal2(s,
serialClone(s));


---


From martinrb at google.com  Tue Jun 18 22:27:41 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Jun 2013 15:27:41 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
	
Message-ID: 

http://cr.openjdk.java.net/~mduigou/JDK-7129185/5/webrev/
seems to be referring to a different changeset/bug
Do you need to fix up mq metadata?

8016446: Improve forEach/replaceAll for Map, HashMap, Hashtable,
IdentityHashMap, WeakHashMap, TreeMap
Reviewed-by: forax, duigou, psandoz


From martinrb at google.com  Tue Jun 18 22:34:08 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Jun 2013 15:34:08 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: <277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
Message-ID: 

Looking at MOAT.java, I'm a little surprised that I didn't systematically
test the implementations in Collections.java, even though e.g. it has a
section for empty collections.  How hard would it be to add such support?


From mandy.chung at oracle.com  Tue Jun 18 22:53:37 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 18 Jun 2013 15:53:37 -0700
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371589723.2524.43.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus>
Message-ID: <51C0E4F1.3080800@oracle.com>

Hi Thomas,

Thanks for the detailed analysis.
> http://cr.openjdk.java.net/~tschatzl/8014890/webrev/

The fix looks good.  I was able to reproduce the failure with the
test case in the bug report running with jdk8 b94 fastdebug build.
But the new regression test doesn't fail (I tried solaris-i586).
Did it fail on your system?

I can sponsor your fix.

Mandy

On 6/18/13 2:08 PM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following change?
>
> It happens if multiple threads are enqueuing and dequeuing reference
> objects into a reference queue, that Reference objects may be enqueued
> at multiple times.
>
> This is because when java.lang.ref.ReferenceQueue.poll() returns and
> inactivates a Reference object, another thread may just be during
> enqueuing it again.
>
> In the test case provided, the two threads that conflict are the
> reference handler thread and the program (main) thread.
>
> Relevant code:
>
> ReferenceHandlerThread.run():
>
> 0: [...]
> 1: ReferenceQueue q = r.queue; // r is the reference
> 2: if (r != ReferenceQueue.NULL)
> 3:   q.enqueue().
>
> ReferenceQueue::poll()(reallyPoll()) code (I removed lots of code here)
>
> 1: synchronized(lock) {
> 2:   [...]
> 3:   r.queue = ReferenceQueue.NULL;
> 3:}
>
> I.e. while ReferenceQueue.poll() sets the Reference's queue to the NULL
> queue so that that reference will not be enqueued again (or at most into
> the NULL queue which is a nop), it happens that if the task switch
> occurs between lines 2 and 3 of the reference handler thread, q still
> contains the old queue reference, and the reference handler thread will
> enqueue the Reference into the original queue again.
>
> You can achieve the same effect by simply calling
> ReferenceQueue.enqueue() (i.e. without the reference handler thread, or
> within the reference handler thread doing the != NULL check), it's just
> that in such a case the "old" ReferenceQueue is stored in some register.
>
> The guard for ReferenceQueue.NULL does not have any effect except for
> possibly saving the virtual call. Simply calling r.enqueue() exhibits
> the same problem.
>
> The proposed solution is to filter out References within
> ReferenceQueue.enqueue() again. At that point we can check whether the
> given Reference is actually meant for this queue or not. Already removed
> References are known to be "inactive" (as enqueue and poll are mutually
> exclusive using a lock), in particular the References' queue is
> different (actually the NULL queue) to the queue it is being enqueued.
>
> This change should pose no change in semantics, as the ReferenceQueue of
> the Reference can only be set in its constructor, and as soon as the
> Reference is removed from a ReferenceQueue, its ReferenceQueue will be
> the NULL queue. (I.e. before this change you could not enqueue such an
> "inactive" Reference multiple times anyway)
>
> (too many References and queues here :)
>
> Webrev with test case
> http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8014890
>
> bugs.sun.com
> http://bugs.sun.com/view_bug.do?bug_id=8014890
>
> Testing:
> jck, jprt, manual testing
>
> Note that I also need a sponsor to push in case this change is approved.
>
> Thanks,
>    Thomas
>



From mike.duigou at oracle.com  Tue Jun 18 23:13:25 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 18 Jun 2013 16:13:25 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C0504C.4060700@cs.oswego.edu>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
Message-ID: 


On Jun 18 2013, at 05:19 , Doug Lea wrote:

> On 06/17/13 19:30, Mike Duigou wrote:
> 
>> 
>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>> 
> 
> Now synched up on my side.
> 
> -Doug
> 



Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.

http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java

Mike

From mike.duigou at oracle.com  Tue Jun 18 23:16:27 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 18 Jun 2013 16:16:27 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C0ACED.80805@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0ACED.80805@univ-mlv.fr>
Message-ID: <8CE61B8E-E1DE-40A0-84C6-E9C1CF966CBA@oracle.com>


On Jun 18 2013, at 11:54 , Remi Forax wrote:

> On 06/18/2013 01:30 AM, Mike Duigou wrote:
> 
> The webrev looks fine for me.
> 
> Nitpicking a little bit, in IdentityHashMap (forEach and replaceAll),
> t[index] is processed twice, by example in forEach, it would prefer this code:
> 
>    public void forEach(BiConsumer action) {
>        Objects.requireNonNull(action);
>        int expectedModCount = modCount;
> 
>        Object[] t = table;
>        for (int index = 0; index < t.length; index += 2) {
>            Object key = t[index];
>            if (key != null) {
>                action.accept((K) unmaskNull(key), (V) t[index + 1]);
>            }
> 
>            if (modCount != expectedModCount)  {
>                throw new ConcurrentModificationException();
>            }
>         }
>    }

Corrected in the pushed version.

> 
> Also there is no curly brace around "throw new CME();"

Also corrected in the pushed version.

> 
> And I have an open question, in ConcurrentMap, the code use entrySet() but could use forEach,
> I wonder which one is better here ?

Good suggestion. I opted for the forEach. A capturing BiConsumer lambda is cheaper than the iterator overhead.

Thanks for your patient and thorough feedback on this issue.

Mike

> cheers,
> R?mi
> 
>> On Jun 17 2013, at 03:09 , Paul Sandoz wrote:
>> 
>>> On Jun 14, 2013, at 11:57 PM, Mike Duigou  wrote:
>>>> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
>>>> 
>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
>>>> 
>>> There are some places where the indentation looks wonky e.g. HashMap & LinkedHashMap changes.
>> I have restyled all of the diffs to make sure they are clean.
>> 
>>> The LinkedHashMap.forEach/replaceAll methods are checking modCount and throwing CME before the action is called.
>> Corrected.
>> 
>>> The WeakHashMap.replaceAll method is checking the modCount per bucket, not-per element.
>> Corrected.
>> 
>>> Are there existing tests for the overriding methods?
>> I had believed so in Map/Defaults.java but replaceAll was absent. Now corrected in updated webrev
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/3/webrev/
>> 
>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>> 
>> Mike
>> 
>> 
>>> Otherwise looks OK.
>>> 
>>> Paul.
>>> 
>>> 
>>>> For interference detection the strategy I am advocating is :
>>>> 
>>>> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.
>>>> 
>>>> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.
>>>> 
>>>> Mike
>>>> 
>>>> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
>>>> 
>>>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>>>> 
>>>>> Revised webrev:
>>>>> 
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>>>> 
>>>>> Mike
>>>>> 
>>>>> 
>>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>> 
>>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>>> Hello all;
>>>>>>> 
>>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>>> 
>>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>>> 
>>>>>>> Mike
>>>>>> Hi Mike,
>>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>>>> 
>>>>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>>>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>>>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>>>>> so you can not do a modCount check only at the end.
>>>>>> 
>>>>>> R?mi
>>>>>> 
>>>>>> Here is the diff.
>>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>>>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>>> @@ -28,6 +28,7 @@
>>>>>> import java.io.*;
>>>>>> import java.lang.reflect.ParameterizedType;
>>>>>> import java.lang.reflect.Type;
>>>>>> +import java.util.function.BiConsumer;
>>>>>> import java.util.function.Consumer;
>>>>>> import java.util.function.BiFunction;
>>>>>> import java.util.function.Function;
>>>>>> @@ -2615,6 +2616,54 @@
>>>>>>  int   capacity()     { return table.length; }
>>>>>>  float loadFactor()   { return loadFactor;   }
>>>>>> 
>>>>>> +
>>>>>> +    @Override
>>>>>> +    public void forEach(BiConsumer action) {
>>>>>> +        Objects.requireNonNull(action);
>>>>>> +        final int expectedModCount = modCount;
>>>>>> +        if (nullKeyEntry != null) {
>>>>>> +            forEachNullKey(expectedModCount, action);
>>>>>> +        }
>>>>>> +        Object[] table = this.table;
>>>>>> +        for(int index = 0; index < table.length; index++) {
>>>>>> +            Object item = table[index];
>>>>>> +            if (item == null) {
>>>>>> +                continue;
>>>>>> +            }
>>>>>> +            if (item instanceof HashMap.TreeBin) {
>>>>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>>>>> +                continue;
>>>>>> +            }
>>>>>> +            @SuppressWarnings("unchecked")
>>>>>> +            Entry entry = (Entry)item;
>>>>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>>>>> +                if (expectedModCount != modCount) {
>>>>>> +                    throw new ConcurrentModificationException();
>>>>>> +                }
>>>>>> +                action.accept(entry.key, entry.value);
>>>>>> +            }
>>>>>> +        }
>>>>>> +    }
>>>>>> +
>>>>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>>>>> +        while (node != null) {
>>>>>> +            if (expectedModCount != modCount) {
>>>>>> +                throw new ConcurrentModificationException();
>>>>>> +            }
>>>>>> +            @SuppressWarnings("unchecked")
>>>>>> +            Entry entry = (Entry)node.entry;
>>>>>> +            action.accept(entry.key, entry.value);
>>>>>> +            node = (TreeNode)entry.next;
>>>>>> +        }
>>>>>> +    }
>>>>>> +
>>>>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>>>>> +        if (expectedModCount != modCount) {
>>>>>> +            throw new ConcurrentModificationException();
>>>>>> +        }
>>>>>> +        action.accept(null, nullKeyEntry.value);
>>>>>> +    }
>>>>>> +
>>>>>>  /**
>>>>>>   * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>>>>   */
>>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>>>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>>> @@ -24,7 +24,8 @@
>>>>>> */
>>>>>> 
>>>>>> package java.util;
>>>>>> -import java.io.*;
>>>>>> +
>>>>>> +import java.util.function.BiConsumer;
>>>>>> 
>>>>>> /**
>>>>>> * 
    Hash table and linked list implementation of the Map interface,
>>>>>> @@ -470,4 +471,16 @@
>>>>>>  protected boolean removeEldestEntry(Map.Entry eldest) {
>>>>>>      return false;
>>>>>>  }
>>>>>> +
>>>>>> +    @Override
>>>>>> +    public void forEach(BiConsumer action) {
>>>>>> +        Objects.requireNonNull(action);
>>>>>> +        int expectedModCount = modCount;
>>>>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>>>>> +            if (expectedModCount != modCount) {
>>>>>> +                throw new ConcurrentModificationException();
>>>>>> +            }
>>>>>> +            action.accept(entry.key, entry.value);
>>>>>> +        }
>>>>>> +    }
>>>>>> }
>>>>>> 
>>>>>> 
> 



From mike.duigou at oracle.com  Tue Jun 18 23:06:05 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 18 Jun 2013 23:06:05 +0000
Subject: hg: jdk8/tl/jdk: 8016446: Improve forEach/replaceAll for Map, HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap, ConcurrentMap
Message-ID: <20130618230619.01903482F0@hg.openjdk.java.net>

Changeset: 1f7cbe4829fe
Author:    mduigou
Date:      2013-06-18 16:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f7cbe4829fe

8016446: Improve forEach/replaceAll for Map, HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap, ConcurrentMap
Reviewed-by: forax, mduigou, psandoz
Contributed-by: Mike Duigou , Remi Forax 

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/WeakHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! test/java/util/Map/Defaults.java



From mike.duigou at oracle.com  Tue Jun 18 23:41:51 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 18 Jun 2013 16:41:51 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
	
Message-ID: <803FCB8D-40A5-4A4D-A669-C5D057D8BAEB@oracle.com>


On Jun 18 2013, at 15:14 , Martin Buchholz wrote:

> Thanks for reusing the existing testing infrastructure I wrote many years ago.

Better than starting from scratch. One aspect which was a bit frustrating and required some changes was the assumption that the result of Navigable.subMap(low,high), etc. can be cast to a Navigable from the basic Map/Set types they are declared to returned. I had not overridden all of the implementations to provide Navigable results and technically I shouldn't have been required to. It seems likely that user code makes the same assumption so I did convert all of the wrappers to return Navigables.

> ---
> I'm a big fan of diversity in testing, and so I much prefer using a different random seed every time to the "reliability" of deterministic tests.

We've been pushing for fully deterministic tests lately to reduce intermittent failures. If more exhaustive testing is needed to produce the same failures as an intermittent random-based testing then hopefully we can always choose to do the additional exhaustive testing.

>  I [assume] you wanted to add repeatability support, you could easily have the test save the initial seed and provide it in case of failure.
> 
> -    static final Random rnd = new Random();
> +    static final Random rnd = new Random(8675309);
I've now changed it back to seeding with a random value, System.nanoTime(), with the seed value printed so that it can be used for reproducing failing cases.

> I don't like the removal of tests below.  Can we find some other way of handling this (perhaps by catching NotSerializableException, as I did in MOAT.java?)
>                     if (! (xxx.getCause() instanceof NotSerializableException))
> -        if (maybe(4) && s instanceof Serializable)
> -            equal2(s, serialClone(s));
> +// mduigou: I had to comment this out for the Collection wrappers which wrap
> +// unserializable sets.
> +//        if (maybe(4) && s instanceof Serializable)
> +//            equal2(s, serialClone(s));

It now catches NotSerializableException and ignores it for this specific case.

Mike

From brian.burkhalter at oracle.com  Wed Jun 19 00:13:03 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Jun 2013 17:13:03 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large	integers
Message-ID: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>

This RFR was initially posted last month:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html

I hope that this is the final re-post. The issues in question are

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474

and the webrev as before is at

http://cr.openjdk.java.net/~bpb/4837946/

The webrev has been updated to include the correlated JTREG test which was not included in the previous post of the webrev.

As previously mentioned, 4837946 and 7131192 touch some of the same code. I will update the webrev of whichever of these is not approved first to get the correct line numbers, but the review process should only nominally be affected as the actual code changes are disjoint.

Thanks,

Brian

From stuart.marks at oracle.com  Wed Jun 19 00:15:12 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Wed, 19 Jun 2013 00:15:12 +0000
Subject: hg: jdk8/tl: 8016780: README-builds.html misses crucial requirement
	on bootstrap JDK
Message-ID: <20130619001512.4C069482F5@hg.openjdk.java.net>

Changeset: b9587f41fd55
Author:    smarks
Date:      2013-06-18 17:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/b9587f41fd55

8016780: README-builds.html misses crucial requirement on bootstrap JDK
Reviewed-by: dholmes, chegar

! README-builds.html



From forax at univ-mlv.fr  Wed Jun 19 00:17:40 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 19 Jun 2013 02:17:40 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <8CE61B8E-E1DE-40A0-84C6-E9C1CF966CBA@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0ACED.80805@univ-mlv.fr>
	<8CE61B8E-E1DE-40A0-84C6-E9C1CF966CBA@oracle.com>
Message-ID: <51C0F8A4.6090607@univ-mlv.fr>

On 06/19/2013 01:16 AM, Mike Duigou wrote:
> On Jun 18 2013, at 11:54 , Remi Forax wrote:
>
>> On 06/18/2013 01:30 AM, Mike Duigou wrote:
>>
>> The webrev looks fine for me.
>>
>> Nitpicking a little bit, in IdentityHashMap (forEach and replaceAll),
>> t[index] is processed twice, by example in forEach, it would prefer this code:
>>
>>     public void forEach(BiConsumer action) {
>>         Objects.requireNonNull(action);
>>         int expectedModCount = modCount;
>>
>>         Object[] t = table;
>>         for (int index = 0; index < t.length; index += 2) {
>>             Object key = t[index];
>>             if (key != null) {
>>                 action.accept((K) unmaskNull(key), (V) t[index + 1]);
>>             }
>>
>>             if (modCount != expectedModCount)  {
>>                 throw new ConcurrentModificationException();
>>             }
>>          }
>>     }
> Corrected in the pushed version.
>
>> Also there is no curly brace around "throw new CME();"
> Also corrected in the pushed version.
>
>> And I have an open question, in ConcurrentMap, the code use entrySet() but could use forEach,
>> I wonder which one is better here ?
> Good suggestion. I opted for the forEach. A capturing BiConsumer lambda is cheaper than the iterator overhead.
>
> Thanks for your patient and thorough feedback on this issue.
>
> Mike

Thanks for having taken my late modifications into account,
and as a user being able to write map.forEach(...) is awesome.

R?mi

>
>> cheers,
>> R?mi
>>
>>> On Jun 17 2013, at 03:09 , Paul Sandoz wrote:
>>>
>>>> On Jun 14, 2013, at 11:57 PM, Mike Duigou  wrote:
>>>>> I have updated the webrev again. In addition to moving the modification checks to be consistently after the operation for the most complete "fast-fail" behaviour I've also slightly enhanced the Map default to detect ISE thrown by setValue as a CME condition.
>>>>>
>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/2/webrev/
>>>>>
>>>> There are some places where the indentation looks wonky e.g. HashMap & LinkedHashMap changes.
>>> I have restyled all of the diffs to make sure they are clean.
>>>
>>>> The LinkedHashMap.forEach/replaceAll methods are checking modCount and throwing CME before the action is called.
>>> Corrected.
>>>
>>>> The WeakHashMap.replaceAll method is checking the modCount per bucket, not-per element.
>>> Corrected.
>>>
>>>> Are there existing tests for the overriding methods?
>>> I had believed so in Map/Defaults.java but replaceAll was absent. Now corrected in updated webrev
>>>
>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/3/webrev/
>>>
>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>
>>> Mike
>>>
>>>
>>>> Otherwise looks OK.
>>>>
>>>> Paul.
>>>>
>>>>
>>>>> For interference detection the strategy I am advocating is :
>>>>>
>>>>> - serial non-stream operations (Collection.forEach/Iterator.forEachRemaining): per-element post-operation ("fast-fail", "best-efforts"). As Remi has pointed out the failure modes for collection.forEach() and for(:collection) will differ and it is a conscious choice to provide superior fast-fail than to match behaviour.
>>>>>
>>>>> - stream terminal operations, both serial and parallel : at completion if at all. Having the serial and parallel stream interference detection behaviours consistent is prioritized over making serial stream behaviour match behaviour of non-stream iteration methods.
>>>>>
>>>>> Mike
>>>>>
>>>>> On Jun 12 2013, at 22:28 , Mike Duigou wrote:
>>>>>
>>>>>> I have updated my webrev with Remi's improvements and some other improvements to the fast-fail concurrent modification checking.
>>>>>>
>>>>>> Revised webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/1/webrev/
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>>>
>>>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>>>> Hello all;
>>>>>>>>
>>>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>>>>
>>>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>>>>
>>>>>>>> Mike
>>>>>>> Hi Mike,
>>>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>>>>>
>>>>>>> My code is slightly different from yours because I've moved the cases where the item is a red/black tree out of the fast path
>>>>>>> (the tree is created either if you are unlucky, if hashCode is badly written or if someone forge keys to have collisions)
>>>>>>> and does the modCount check for each element because a call to the consumer can change the underlying map
>>>>>>> so you can not do a modCount check only at the end.
>>>>>>>
>>>>>>> R?mi
>>>>>>>
>>>>>>> Here is the diff.
>>>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/HashMap.java
>>>>>>> --- a/src/share/classes/java/util/HashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>>>> +++ b/src/share/classes/java/util/HashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>>>> @@ -28,6 +28,7 @@
>>>>>>> import java.io.*;
>>>>>>> import java.lang.reflect.ParameterizedType;
>>>>>>> import java.lang.reflect.Type;
>>>>>>> +import java.util.function.BiConsumer;
>>>>>>> import java.util.function.Consumer;
>>>>>>> import java.util.function.BiFunction;
>>>>>>> import java.util.function.Function;
>>>>>>> @@ -2615,6 +2616,54 @@
>>>>>>>   int   capacity()     { return table.length; }
>>>>>>>   float loadFactor()   { return loadFactor;   }
>>>>>>>
>>>>>>> +
>>>>>>> +    @Override
>>>>>>> +    public void forEach(BiConsumer action) {
>>>>>>> +        Objects.requireNonNull(action);
>>>>>>> +        final int expectedModCount = modCount;
>>>>>>> +        if (nullKeyEntry != null) {
>>>>>>> +            forEachNullKey(expectedModCount, action);
>>>>>>> +        }
>>>>>>> +        Object[] table = this.table;
>>>>>>> +        for(int index = 0; index < table.length; index++) {
>>>>>>> +            Object item = table[index];
>>>>>>> +            if (item == null) {
>>>>>>> +                continue;
>>>>>>> +            }
>>>>>>> +            if (item instanceof HashMap.TreeBin) {
>>>>>>> +                eachTreeNode(expectedModCount, ((TreeBin)item).first, action);
>>>>>>> +                continue;
>>>>>>> +            }
>>>>>>> +            @SuppressWarnings("unchecked")
>>>>>>> +            Entry entry = (Entry)item;
>>>>>>> +            for (;entry != null; entry = (Entry)entry.next) {
>>>>>>> +                if (expectedModCount != modCount) {
>>>>>>> +                    throw new ConcurrentModificationException();
>>>>>>> +                }
>>>>>>> +                action.accept(entry.key, entry.value);
>>>>>>> +            }
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    private void eachTreeNode(int expectedModCount, TreeNode node, BiConsumer action) {
>>>>>>> +        while (node != null) {
>>>>>>> +            if (expectedModCount != modCount) {
>>>>>>> +                throw new ConcurrentModificationException();
>>>>>>> +            }
>>>>>>> +            @SuppressWarnings("unchecked")
>>>>>>> +            Entry entry = (Entry)node.entry;
>>>>>>> +            action.accept(entry.key, entry.value);
>>>>>>> +            node = (TreeNode)entry.next;
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> +
>>>>>>> +    private void forEachNullKey(int expectedModCount, BiConsumer action) {
>>>>>>> +        if (expectedModCount != modCount) {
>>>>>>> +            throw new ConcurrentModificationException();
>>>>>>> +        }
>>>>>>> +        action.accept(null, nullKeyEntry.value);
>>>>>>> +    }
>>>>>>> +
>>>>>>>   /**
>>>>>>>    * Standin until HM overhaul; based loosely on Weak and Identity HM.
>>>>>>>    */
>>>>>>> diff -r 6df79b7bae6f src/share/classes/java/util/LinkedHashMap.java
>>>>>>> --- a/src/share/classes/java/util/LinkedHashMap.java    Wed Jun 12 09:44:34 2013 +0100
>>>>>>> +++ b/src/share/classes/java/util/LinkedHashMap.java    Thu Jun 13 00:46:05 2013 +0200
>>>>>>> @@ -24,7 +24,8 @@
>>>>>>> */
>>>>>>>
>>>>>>> package java.util;
>>>>>>> -import java.io.*;
>>>>>>> +
>>>>>>> +import java.util.function.BiConsumer;
>>>>>>>
>>>>>>> /**
>>>>>>> * 
    Hash table and linked list implementation of the Map interface,
>>>>>>> @@ -470,4 +471,16 @@
>>>>>>>   protected boolean removeEldestEntry(Map.Entry eldest) {
>>>>>>>       return false;
>>>>>>>   }
>>>>>>> +
>>>>>>> +    @Override
>>>>>>> +    public void forEach(BiConsumer action) {
>>>>>>> +        Objects.requireNonNull(action);
>>>>>>> +        int expectedModCount = modCount;
>>>>>>> +        for (Entry entry = header.after; entry != header; entry = entry.after) {
>>>>>>> +            if (expectedModCount != modCount) {
>>>>>>> +                throw new ConcurrentModificationException();
>>>>>>> +            }
>>>>>>> +            action.accept(entry.key, entry.value);
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> }
>>>>>>>
>>>>>>>



From brian.burkhalter at oracle.com  Wed Jun 19 00:45:43 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Jun 2013 17:45:43 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
	
Message-ID: 

The updated comments have been propagated to the online webrev

http://cr.openjdk.java.net/~bpb/7131192/

On Jun 17, 2013, at 11:39 AM, Brian Burkhalter wrote:

> I'll update this but without reposting the webrev until I can upload the HTML version.
> 
> On Jun 17, 2013, at 11:37 AM, Louis Wasserman wrote:
> 
>> You're right, it'd be WIDTH - 1, but since most of the comments refer to BITS + 1, that evens out nicely.
>> 
>> On Mon, Jun 17, 2013 at 11:34 AM, Brian Burkhalter wrote:
>> Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied" bit?
>> 
>> On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:
>> 
>> > The comments mention SIGNIFICAND_BITS, which I think should probably be SIGNIFICAND_WIDTH?
> 



From martinrb at google.com  Wed Jun 19 00:51:42 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Jun 2013 17:51:42 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
Message-ID: 

As always, I hope that those folks who deeply understand math stuff
can be empowered to submit/review.

Looks good, except for some minor style issues:


Probably want to leave debug print commented out in the final version?

-                //System.err.println(x+": "+bitCount+", "+bigX.bitCount());
+                System.err.println(x+": "+bitCount+", "+bigX.bitCount());


Even for private methods, we should use standard javadoc style, so add
missing asterisks below.

+    /** Returns a slice of a BigInteger for use in Toom-Cook multiplication.
+        @param lowerSize The size of the lower-order bit slices.
+        @param upperSize The size of the higher-order bit slices.
+        @param slice The index of which slice is requested, which must be a
+                     number from 0 to size-1.  Slice 0 is the highest-order
+                     bits, and slice size-1 are the lowest-order bits.
+                     Slice 0 may be of different size than the other slices.
+        @param fullsize The size of the larger integer array, used to align
+                        slices to the appropriate position when multiplying
+                        different-sized numbers.
+    */


From brian.burkhalter at oracle.com  Wed Jun 19 00:55:37 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 18 Jun 2013 17:55:37 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: 
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
	
Message-ID: <867870E6-A79E-4645-B238-2BF4FCB171E0@oracle.com>

On Jun 18, 2013, at 5:51 PM, Martin Buchholz wrote:
> As always, I hope that those folks who deeply understand math stuff can be empowered to submit/review.
> Looks good, except for some minor style issues:
> Probably want to leave debug print commented out in the final version?
> -                //System.err.println(x+": "+bitCount+", "+bigX.bitCount());
> +                System.err.println(x+": "+bitCount+", "+bigX.bitCount());
These are in the test only and unlikely to be printed, but if they were no harm is done.

> Even for private methods, we should use standard javadoc style, so add missing asterisks below.
> +    /** Returns a slice of a BigInteger for use in Toom-Cook multiplication.
> +        @param lowerSize The size of the lower-order bit slices.
> +        @param upperSize The size of the higher-order bit slices.
> +        @param slice The index of which slice is requested, which must be a
> +                     number from 0 to size-1.  Slice 0 is the highest-order
> +                     bits, and slice size-1 are the lowest-order bits.
> +                     Slice 0 may be of different size than the other slices.
> +        @param fullsize The size of the larger integer array, used to align
> +                        slices to the appropriate position when multiplying
> +                        different-sized numbers.
> +    */
I'll incorporate this change with any others if any which are suggested prior to integration.

Thanks,

Brian

From mike.duigou at oracle.com  Wed Jun 19 00:59:18 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 18 Jun 2013 17:59:18 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
	
Message-ID: 

I have now updated MOAT to test the Collections wrappers. I hope that adding additional classes doesn't take the already long runtime of this class over the timeout threshold.

The revised webrev, which includes only changes to tests, is here:

http://cr.openjdk.java.net/~mduigou/JDK-7129185/6/webrev/

The very pleasing news is that nothing failed! 

Mike

On Jun 18 2013, at 15:34 , Martin Buchholz wrote:

> 
> Looking at MOAT.java, I'm a little surprised that I didn't systematically test the implementations in Collections.java, even though e.g. it has a section for empty collections.  How hard would it be to add such support?



From martinrb at google.com  Wed Jun 19 01:12:34 2013
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Jun 2013 18:12:34 -0700
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
	
	
Message-ID: 

Looks good.

+        catch (Throwable e) {
+            if (e instanceof Error) {
+                throw (Error) e;
+            } else if (e instanceof RuntimeException) {
+                throw (RuntimeException) e;
+            } else {
+                throw new RuntimeException(e);
+            }


You can take advantage of those new-fangled language features to make this
a little less boilerplatey.

        catch (Error|RuntimeException e) { throw e; }
        catch (Throwable e) { throw new RuntimeException(e); }



On Tue, Jun 18, 2013 at 5:59 PM, Mike Duigou  wrote:

> I have now updated MOAT to test the Collections wrappers. I hope that
> adding additional classes doesn't take the already long runtime of this
> class over the timeout threshold.
>
> The revised webrev, which includes only changes to tests, is here:
>
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/6/webrev/
>
> The very pleasing news is that nothing failed!
>
> Mike
>
> On Jun 18 2013, at 15:34 , Martin Buchholz wrote:
>
> >
> > Looking at MOAT.java, I'm a little surprised that I didn't
> systematically test the implementations in Collections.java, even though
> e.g. it has a section for empty collections.  How hard would it be to add
> such support?
>
>


From xuelei.fan at oracle.com  Wed Jun 19 01:51:28 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 19 Jun 2013 01:51:28 +0000
Subject: hg: jdk8/tl/jdk: 8000456: Add programmatic deadlock detection in
	SSLEngineDeadlock
Message-ID: <20130619015140.2BA02482FC@hg.openjdk.java.net>

Changeset: 2d9da733014f
Author:    xuelei
Date:      2013-06-18 18:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d9da733014f

8000456: Add programmatic deadlock detection in SSLEngineDeadlock
Reviewed-by: wetmore

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java



From david.holmes at oracle.com  Wed Jun 19 02:47:19 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Jun 2013 12:47:19 +1000
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371589723.2524.43.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus>
Message-ID: <51C11BB7.9030202@oracle.com>

Hi Thomas,

On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following change?
>
> It happens if multiple threads are enqueuing and dequeuing reference
> objects into a reference queue, that Reference objects may be enqueued
> at multiple times.
>
> This is because when java.lang.ref.ReferenceQueue.poll() returns and
> inactivates a Reference object, another thread may just be during
> enqueuing it again.

Are we talking about different queues here? Otherwise both poll() and 
enqueue() are using synchronized(lock). I also note that enqueue 
synchronizes on the Reference itself, which suggests that poll (actually 
reallyPoll) should also be synchronizing on the reference (though we 
have a nested lock inversion problem that would need to be solved).

David
-----

> In the test case provided, the two threads that conflict are the
> reference handler thread and the program (main) thread.
>
> Relevant code:
>
> ReferenceHandlerThread.run():
>
> 0: [...]
> 1: ReferenceQueue q = r.queue; // r is the reference
> 2: if (r != ReferenceQueue.NULL)
> 3:   q.enqueue().
>
> ReferenceQueue::poll()(reallyPoll()) code (I removed lots of code here)
>
> 1: synchronized(lock) {
> 2:   [...]
> 3:   r.queue = ReferenceQueue.NULL;
> 3:}
>
> I.e. while ReferenceQueue.poll() sets the Reference's queue to the NULL
> queue so that that reference will not be enqueued again (or at most into
> the NULL queue which is a nop), it happens that if the task switch
> occurs between lines 2 and 3 of the reference handler thread, q still
> contains the old queue reference, and the reference handler thread will
> enqueue the Reference into the original queue again.
>
> You can achieve the same effect by simply calling
> ReferenceQueue.enqueue() (i.e. without the reference handler thread, or
> within the reference handler thread doing the != NULL check), it's just
> that in such a case the "old" ReferenceQueue is stored in some register.
>
> The guard for ReferenceQueue.NULL does not have any effect except for
> possibly saving the virtual call. Simply calling r.enqueue() exhibits
> the same problem.
>
> The proposed solution is to filter out References within
> ReferenceQueue.enqueue() again. At that point we can check whether the
> given Reference is actually meant for this queue or not. Already removed
> References are known to be "inactive" (as enqueue and poll are mutually
> exclusive using a lock), in particular the References' queue is
> different (actually the NULL queue) to the queue it is being enqueued.
>
> This change should pose no change in semantics, as the ReferenceQueue of
> the Reference can only be set in its constructor, and as soon as the
> Reference is removed from a ReferenceQueue, its ReferenceQueue will be
> the NULL queue. (I.e. before this change you could not enqueue such an
> "inactive" Reference multiple times anyway)
>
> (too many References and queues here :)
>
> Webrev with test case
> http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
>
> JIRA:
> https://jbs.oracle.com/bugs/browse/JDK-8014890
>
> bugs.sun.com
> http://bugs.sun.com/view_bug.do?bug_id=8014890
>
> Testing:
> jck, jprt, manual testing
>
> Note that I also need a sponsor to push in case this change is approved.
>
> Thanks,
>    Thomas
>


From michael.fang at oracle.com  Wed Jun 19 04:39:43 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 19 Jun 2013 04:39:43 +0000
Subject: hg: jdk8/tl/langtools: 8015657: jdk8 l10n resource file translation
	update 3
Message-ID: <20130619043946.7B0CA48312@hg.openjdk.java.net>

Changeset: 792c40d5185a
Author:    mfang
Date:      2013-06-18 20:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/792c40d5185a

8015657: jdk8 l10n resource file translation update 3
Reviewed-by: yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
+ src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties
+ src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
+ src/share/classes/com/sun/tools/javap/resources/javap_ja.properties
+ src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties
+ src/share/classes/com/sun/tools/jdeps/resources/jdeps_ja.properties
+ src/share/classes/com/sun/tools/jdeps/resources/jdeps_zh_CN.properties



From michael.fang at oracle.com  Wed Jun 19 04:39:06 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 19 Jun 2013 04:39:06 +0000
Subject: hg: jdk8/tl/jdk: 8015657: jdk8 l10n resource file translation update 3
Message-ID: <20130619043918.2637048311@hg.openjdk.java.net>

Changeset: d82773b770ce
Author:    mfang
Date:      2013-06-18 21:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d82773b770ce

8015657: jdk8 l10n resource file translation update 3
Reviewed-by: yhuang

! src/macosx/classes/com/apple/laf/resources/aqua_pt_BR.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties
! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties
! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties
! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java
! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java
! src/share/classes/sun/launcher/resources/launcher_de.properties
! src/share/classes/sun/launcher/resources/launcher_es.properties
! src/share/classes/sun/launcher/resources/launcher_fr.properties
! src/share/classes/sun/launcher/resources/launcher_it.properties
! src/share/classes/sun/launcher/resources/launcher_ja.properties
! src/share/classes/sun/launcher/resources/launcher_ko.properties
! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties
! src/share/classes/sun/launcher/resources/launcher_sv.properties
! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties
! src/share/classes/sun/security/util/AuthResources_zh_CN.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_TW.java
! src/share/classes/sun/tools/jar/resources/jar_de.properties
! src/share/classes/sun/tools/jar/resources/jar_es.properties
! src/share/classes/sun/tools/jar/resources/jar_fr.properties
! src/share/classes/sun/tools/jar/resources/jar_it.properties
! src/share/classes/sun/tools/jar/resources/jar_ja.properties
! src/share/classes/sun/tools/jar/resources/jar_ko.properties
! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties
! src/share/classes/sun/tools/jar/resources/jar_sv.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties
! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties
! src/share/classes/sun/tools/serialver/serialver_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_de.properties
! src/share/classes/sun/util/logging/resources/logging_es.properties
! src/share/classes/sun/util/logging/resources/logging_fr.properties
! src/share/classes/sun/util/logging/resources/logging_it.properties
! src/share/classes/sun/util/logging/resources/logging_ja.properties
! src/share/classes/sun/util/logging/resources/logging_ko.properties
! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
! src/share/classes/sun/util/logging/resources/logging_sv.properties
! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties



From michael.fang at oracle.com  Wed Jun 19 04:37:06 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 19 Jun 2013 04:37:06 +0000
Subject: hg: jdk8/tl/corba: 8015657: jdk8 l10n resource file translation
	update 3
Message-ID: <20130619043707.9B3D14830F@hg.openjdk.java.net>

Changeset: d406edd4f6fd
Author:    mfang
Date:      2013-06-18 20:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/d406edd4f6fd

8015657: jdk8 l10n resource file translation update 3
Reviewed-by: yhuang

! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties
! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp
! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp



From michael.fang at oracle.com  Wed Jun 19 05:52:53 2013
From: michael.fang at oracle.com (michael.fang at oracle.com)
Date: Wed, 19 Jun 2013 05:52:53 +0000
Subject: hg: jdk8/tl/jaxp: 8016824: jdk8 l10n resource file translation update
	3 - jaxp
Message-ID: <20130619055257.A102848313@hg.openjdk.java.net>

Changeset: 21d9cbbb7bf3
Author:    mfang
Date:      2013-06-18 22:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/21d9cbbb7bf3

8016824: jdk8 l10n resource file translation update 3 - jaxp
Reviewed-by: joehw

! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
! src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_de.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_es.properties
! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_it.properties
! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ko.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_pt_BR.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_sv.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_CN.properties
+ src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_zh_TW.properties



From peter.levart at gmail.com  Wed Jun 19 06:44:46 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 08:44:46 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: 
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
Message-ID: <51C1535E.5070105@gmail.com>

On 06/19/2013 01:13 AM, Mike Duigou wrote:
> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>
>> On 06/17/13 19:30, Mike Duigou wrote:
>>
>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>
>> Now synched up on my side.
>>
>> -Doug
>>
>
>
> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java
>
> Mike

Hi Mike, Remi,

Since forEach implementation can be taken from default Map.forEach in 
some implementations of ConcurrentMap, and that implementation is based 
on entrySet Iterator, isn't it dangerous for this to trigger 
ConcurrentModificationException in some implementation of ConcurrentMap? 
I see nothing in the spec. of ConcurrentMap that suggests it's entrySet 
iterators are never fail-fast. They can be prepared for modifications 
from other threads (synchronization), but may not tolerate re-entrant calls.

For example some implementation of (Concurrent)Map could be structurally 
modified as a result of Map.replace(key, old, new) - imagine a 
ConcurrentWeakHashMap that expunges stale entries on each call - and 
forEach iteration may not be prepared to handle such situations.

Regards, Peter



From peter.levart at gmail.com  Wed Jun 19 07:08:52 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 09:08:52 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C1535E.5070105@gmail.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
Message-ID: <51C15904.4050806@gmail.com>

On 06/19/2013 08:44 AM, Peter Levart wrote:
> On 06/19/2013 01:13 AM, Mike Duigou wrote:
>> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>>
>>> On 06/17/13 19:30, Mike Duigou wrote:
>>>
>>>> I had to add the improved default for ConcurrentMap which was 
>>>> present in the lambda repo in order to have correct behaviour. 
>>>> Since getOrDefault is already in ConcurrentMap I will include this 
>>>> but we have to be careful when we do a jsr 166 syncup to make sure 
>>>> that the defaults don't get lost.
>>>>
>>> Now synched up on my side.
>>>
>>> -Doug
>>>
>>
>>
>> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll 
>> default to use forEach. This trades off the entrySet iterator 
>> overhead for creation of a capturing BiConsumer lambda.
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java 
>>
>>
>> Mike
>
> Hi Mike, Remi,
>
> Since forEach implementation can be taken from default Map.forEach in 
> some implementations of ConcurrentMap, and that implementation is 
> based on entrySet Iterator, isn't it dangerous for this to trigger 
> ConcurrentModificationException in some implementation of 
> ConcurrentMap? I see nothing in the spec. of ConcurrentMap that 
> suggests it's entrySet iterators are never fail-fast. They can be 
> prepared for modifications from other threads (synchronization), but 
> may not tolerate re-entrant calls.
>
> For example some implementation of (Concurrent)Map could be 
> structurally modified as a result of Map.replace(key, old, new) - 
> imagine a ConcurrentWeakHashMap that expunges stale entries on each 
> call - and forEach iteration may not be prepared to handle such 
> situations.
>
> Regards, Peter
>

Hi Mike,

I'd also like to suggest something. You have made lots of tests that 
cover the functionality of new default methods in Map and other 
collections interfaces which prove the correctness of behaviour when 
used with implementations of those interfaces in JDK. Perhaps It would 
be wise to extend those tests to include some JDK-external 
implementations that are known to pass basic tests, taken for example 
from Guava or Apache Commons or even JDK7. The interactions of default 
methods with existing methods in various implementations of collection 
interfaces could reveal "bugs" that may be on the part of default 
methods. I'm sure the maintainers of these external implementations will 
do the same, but may be doing that only after JDK8 release.

Regards, Peter



From thomas.schatzl at oracle.com  Wed Jun 19 07:17:30 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 09:17:30 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C11BB7.9030202@oracle.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
Message-ID: <1371626250.2715.19.camel@cirrus>


Hi,

On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> Hi Thomas,
> 
> On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> > Hi all,
> >
> >    can I have reviews for the following change?
> >
> > It happens if multiple threads are enqueuing and dequeuing reference
> > objects into a reference queue, that Reference objects may be enqueued
> > at multiple times.
> >
> > This is because when java.lang.ref.ReferenceQueue.poll() returns and
> > inactivates a Reference object, another thread may just be during
> > enqueuing it again.
> 
> Are we talking about different queues here? Otherwise both poll() and 
> enqueue() are using synchronized(lock). I also note that enqueue 
> synchronizes on the Reference itself, which suggests that poll (actually 
> reallyPoll) should also be synchronizing on the reference (though we 
> have a nested lock inversion problem that would need to be solved).

This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.

Enqueue() and (really-)poll() themselves already synchronize on the
"lock" lock to guard modification of the queue, this is safe.

The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.

Another solution would be to synchronize enqueue() and poll() on the queue itself, and check whether the reference passed to enqueue() is inactive or not (i.e. this check is still needed).

> > ReferenceHandlerThread.run():
> >
> > 0: [...]
> > 1: ReferenceQueue q = r.queue; // r is the reference
> > 2: if (r != ReferenceQueue.NULL)
> > 3:   q.enqueue().

Between lines 2 and 3, q contains a reference to the old ReferenceQueue (which is not ReferenceQueue.NULL). So if the thread is switched there, i.e. the main thread does a poll() on q, the main thread makes r inactive. When switching back to the reference handler thread (or any other thread), enqueue() of that Reference r will still be called on the original q. The actual r.queue is already ReferenceQueue.NULL from the poll(). (i.e. the Reference is inactive). This change guards against that situation as this is (imo) an unexpected behavior (that you can enqueue a Reference multiple times; and an already inactive one too).

The only solution would be synchronizing on r in the ReferenceHandler code to avoid that (I think). However then everyone that uses Reference.enqueue() (which uses ReferenceQueue.enqueue()) would need to synchronize on the Reference to make the code thread safe. I haven't seen that in the documentation.

As mentioned this situation may occur independently of whether the ReferenceHandler thread is involved or not.

I.e. if you look at Reference.enqueue() which reads as

  this.queue.enqueue(this)

This is the same situation, if you consider that "this.queue" may be temporarily stored in e.g. a register during the thread switch.


> > Webrev with test case
> > http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
> >
> > JIRA:
> > https://jbs.oracle.com/bugs/browse/JDK-8014890
> >
> > bugs.sun.com
> > http://bugs.sun.com/view_bug.do?bug_id=8014890
> >
> > Testing:
> > jck, jprt, manual testing
> >
> > Note that I also need a sponsor to push in case this change is approved.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Wed Jun 19 07:25:04 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 09:25:04 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C0E4F1.3080800@oracle.com>
References: <1371589723.2524.43.camel@cirrus> <51C0E4F1.3080800@oracle.com>
Message-ID: <1371626704.2715.23.camel@cirrus>

Hi,

On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
> Hi Thomas,
> 
> Thanks for the detailed analysis.
> > http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
> 
> The fix looks good.  I was able to reproduce the failure with the
> test case in the bug report running with jdk8 b94 fastdebug build.
> But the new regression test doesn't fail (I tried solaris-i586).
> Did it fail on your system?
> 

Yes, 100% on my developer machine. I will try to modify it to make it
fail on more machines (increase number of runs).

It is hard to reproduce such things consistently, but I think we nailed
down the issue and that's probably what counts in such cases.

Also consider that this issue has likely been present since quite some
time, and has only been noticed and investigated just now.

> I can sponsor your fix.

Thanks,
  Thomas




From thomas.schatzl at oracle.com  Wed Jun 19 07:28:25 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 09:28:25 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371626250.2715.19.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus>
Message-ID: <1371626905.2715.25.camel@cirrus>

Hi again,

  some correction...

On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> > Hi Thomas,
> > 
> > On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> > > Hi all,
> > >
> > >    can I have reviews for the following change?
> > >
> > > It happens if multiple threads are enqueuing and dequeuing reference
> > > objects into a reference queue, that Reference objects may be enqueued
> > > at multiple times.
> > >
> > > This is because when java.lang.ref.ReferenceQueue.poll() returns and
> > > inactivates a Reference object, another thread may just be during
> > > enqueuing it again.
> > 
> > Are we talking about different queues here? Otherwise both poll() and 
> > enqueue() are using synchronized(lock). I also note that enqueue 
> > synchronizes on the Reference itself, which suggests that poll (actually 
> > reallyPoll) should also be synchronizing on the reference (though we 
> > have a nested lock inversion problem that would need to be solved).
> 
> This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.
> 
> Enqueue() and (really-)poll() themselves already synchronize on the
> "lock" lock to guard modification of the queue, this is safe.
> 
> The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.

This also guards against multiple concurrent calls to enqueue on the
same reference - so this statement is needed after all.

Sorry,
  Thomas




From thomas.schatzl at oracle.com  Wed Jun 19 07:34:05 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 09:34:05 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371626905.2715.25.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
Message-ID: <1371627245.2715.28.camel@cirrus>

Hi,

 one more note :)

On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote:
> Hi again,
> 
>   some correction...
> 
> On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
> > Hi,
> > 
> > On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> > > Hi Thomas,
> > > 
> > > On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> > > > Hi all,
> > > >
> > > >    can I have reviews for the following change?
> > > >
> > > > It happens if multiple threads are enqueuing and dequeuing reference
> > > > objects into a reference queue, that Reference objects may be enqueued
> > > > at multiple times.
> > > >
> > > > This is because when java.lang.ref.ReferenceQueue.poll() returns and
> > > > inactivates a Reference object, another thread may just be during
> > > > enqueuing it again.
> > > 
> > > Are we talking about different queues here? Otherwise both poll() and 
> > > enqueue() are using synchronized(lock). I also note that enqueue 
> > > synchronizes on the Reference itself, which suggests that poll (actually 
> > > reallyPoll) should also be synchronizing on the reference (though we 
> > > have a nested lock inversion problem that would need to be solved).
> > 
> > This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.
> > 
> > Enqueue() and (really-)poll() themselves already synchronize on the
> > "lock" lock to guard modification of the queue, this is safe.
> > 
> > The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.
> 
> This also guards against multiple concurrent calls to enqueue on the
> same reference - so this statement is needed after all.

Actually, with that patch (e.g. the if (this != r.queue check) return
false; ) this situation would also be covered I think.

But that's unrelated, sorry.

Thomas




From daniel.fuchs at oracle.com  Wed Jun 19 09:00:42 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 19 Jun 2013 11:00:42 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51BA2601.3070609@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
Message-ID: <51C1733A.7020008@oracle.com>

On 6/13/13 10:05 PM, Mandy Chung wrote:
> Daniel,
>
> I wonder what the list of logger names (loggers1 and loggers2) returned
> by LoggingMXBean contains and that may include loggers in the running VM
> other than the ones created and kept a strong reference by the test. In
> other words,  would it be possible for the running VM that has loggers
> that are not created by the test and got GC'ed?

Hi Mandy,

I have added a System.out.println to print the list of logger names.
By running jtreg on my machine I could see that this list does contain
system logger names (mostly JMX loggers).
I believe those loggers are strongly referenced by JMX.
Other than those I could see "" and "global".



However - since this seems to be an intermittent failure - maybe the
logger that was causing the problem had already been gc'ed before
getLoggerNames() and therefore didn't appear in this list.
The test would fail when that 'transient' logger appears in the
list but is gc'ed before getLoggerLevel() is called.

Anyway - it's possible that some platform class
is calling:
    Logger log = Logger.getLogger();
    if (log.isLoggable()) {...}
without keeping a strong reference to the logger in the class.

In that case I guess it would be possible for that 
to appear transiently in the logger's name list - and be gc'ed
just after...

-- daniel

>
> Mandy
>
> On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below an attempt at fixing
>> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
>>
>> This is an intermittent failure which I haven't managed to reproduce,
>> so I am reduced to figure out what could have gone wrong by analyzing
>> the code.
>>
>> AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
>> returns null - which I believe can only happen
>> when LogManager.getLogger() returns null.
>>
>> I see that LogManager uses weak references to hold loggers - so my
>> suspicion is that one of the logger whose name had been returned by
>> getLoggerNames() has been gc'ed in between the two calls.
>>
>> I have modified the code to accept this possibility - excluding the
>> two loggers for which the test itself holds a strong reference, as
>> these should not have been gc'ed.
>>
>> I can't guarantee that it will fix the issue, but if it does not,
>> we will at least be able to disregard this possibility :-)
>>
>> 
>>
>> -- daniel
>



From daniel.fuchs at oracle.com  Wed Jun 19 09:03:01 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 19 Jun 2013 11:03:01 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51C1733A.7020008@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
	<51C1733A.7020008@oracle.com>
Message-ID: <51C173C5.5060800@oracle.com>

On 6/19/13 11:00 AM, Daniel Fuchs wrote:
> On 6/13/13 10:05 PM, Mandy Chung wrote:
>> Daniel,
>>
>> I wonder what the list of logger names (loggers1 and loggers2) returned
>> by LoggingMXBean contains and that may include loggers in the running VM
>> other than the ones created and kept a strong reference by the test. In
>> other words,  would it be possible for the running VM that has loggers
>> that are not created by the test and got GC'ed?
>
> Hi Mandy,
>
> I have added a System.out.println to print the list of logger names.
> By running jtreg on my machine I could see that this list does contain
> system logger names (mostly JMX loggers).
> I believe those loggers are strongly referenced by JMX.
> Other than those I could see "" and "global".
>
> 
                                                         ^^^^


sorry...

-- daniel

>
> However - since this seems to be an intermittent failure - maybe the
> logger that was causing the problem had already been gc'ed before
> getLoggerNames() and therefore didn't appear in this list.
> The test would fail when that 'transient' logger appears in the
> list but is gc'ed before getLoggerLevel() is called.
>
> Anyway - it's possible that some platform class
> is calling:
>     Logger log = Logger.getLogger();
>     if (log.isLoggable()) {...}
> without keeping a strong reference to the logger in the class.
>
> In that case I guess it would be possible for that 
> to appear transiently in the logger's name list - and be gc'ed
> just after...
>
> -- daniel
>
>>
>> Mandy
>>
>> On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below an attempt at fixing
>>> test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
>>>
>>> This is an intermittent failure which I haven't managed to reproduce,
>>> so I am reduced to figure out what could have gone wrong by analyzing
>>> the code.
>>>
>>> AFAICT the NPE is thrown when LoggingMXBean.getLogerLevel(logger)
>>> returns null - which I believe can only happen
>>> when LogManager.getLogger() returns null.
>>>
>>> I see that LogManager uses weak references to hold loggers - so my
>>> suspicion is that one of the logger whose name had been returned by
>>> getLoggerNames() has been gc'ed in between the two calls.
>>>
>>> I have modified the code to accept this possibility - excluding the
>>> two loggers for which the test itself holds a strong reference, as
>>> these should not have been gc'ed.
>>>
>>> I can't guarantee that it will fix the issue, but if it does not,
>>> we will at least be able to disregard this possibility :-)
>>>
>>> 
>>>
>>> -- daniel
>>
>



From peter.levart at gmail.com  Wed Jun 19 09:05:23 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 11:05:23 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371626250.2715.19.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus>
Message-ID: <51C17453.60400@gmail.com>

On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
>> Hi Thomas,
>>
>> On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
>>> Hi all,
>>>
>>>     can I have reviews for the following change?
>>>
>>> It happens if multiple threads are enqueuing and dequeuing reference
>>> objects into a reference queue, that Reference objects may be enqueued
>>> at multiple times.
>>>
>>> This is because when java.lang.ref.ReferenceQueue.poll() returns and
>>> inactivates a Reference object, another thread may just be during
>>> enqueuing it again.
>> Are we talking about different queues here? Otherwise both poll() and
>> enqueue() are using synchronized(lock). I also note that enqueue
>> synchronizes on the Reference itself, which suggests that poll (actually
>> reallyPoll) should also be synchronizing on the reference (though we
>> have a nested lock inversion problem that would need to be solved).
> This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.
>
> Enqueue() and (really-)poll() themselves already synchronize on the
> "lock" lock to guard modification of the queue, this is safe.
>
> The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.

Hi Thomas,

It doesn't make a difference between Reference.isEnqueued() and 
ReferenceQueue.poll(), since there isn't any synchronization between the 
two. So isEnqueued() can still be returning true while another thread 
has already de-queued the instance. I guess the real use of isEnqueued() 
method is reliable detection of false -> true transition only.

I can't see why the isEnqueued() method checks for both (next != null && 
queue == ENQUEUED). Wouldn't the check for (queue == ENQUEUED) be 
enough? In that case the Reference.queue field could be made volatile 
and synchronization on Reference instance removed.

While you're at it, the reallyPoll() could optimize the double volatile 
read from head and only perform it once:

     private Reference reallyPoll() {       /* Must hold 
lock */
         Reference r = head;
         if (r != null) {
             head = (r.next == r) ? null : r.next;
             r.queue = NULL;
             r.next = r;
             queueLength--;
             if (r instanceof FinalReference) {
                 sun.misc.VM.addFinalRefCount(-1);
             }
             return r;
         }
         return null;
     }


>
> Another solution would be to synchronize enqueue() and poll() on the queue itself, and check whether the reference passed to enqueue() is inactive or not (i.e. this check is still needed).

ReferenceQueue.this and ReferenceQueue.lock are 1<->1. What difference 
would that make?

Regards, Peter

>
>>> ReferenceHandlerThread.run():
>>>
>>> 0: [...]
>>> 1: ReferenceQueue q = r.queue; // r is the reference
>>> 2: if (r != ReferenceQueue.NULL)
>>> 3:   q.enqueue().
> Between lines 2 and 3, q contains a reference to the old ReferenceQueue (which is not ReferenceQueue.NULL). So if the thread is switched there, i.e. the main thread does a poll() on q, the main thread makes r inactive. When switching back to the reference handler thread (or any other thread), enqueue() of that Reference r will still be called on the original q. The actual r.queue is already ReferenceQueue.NULL from the poll(). (i.e. the Reference is inactive). This change guards against that situation as this is (imo) an unexpected behavior (that you can enqueue a Reference multiple times; and an already inactive one too).
>
> The only solution would be synchronizing on r in the ReferenceHandler code to avoid that (I think). However then everyone that uses Reference.enqueue() (which uses ReferenceQueue.enqueue()) would need to synchronize on the Reference to make the code thread safe. I haven't seen that in the documentation.
>
> As mentioned this situation may occur independently of whether the ReferenceHandler thread is involved or not.
>
> I.e. if you look at Reference.enqueue() which reads as
>
>    this.queue.enqueue(this)
>
> This is the same situation, if you consider that "this.queue" may be temporarily stored in e.g. a register during the thread switch.
>
>
>>> Webrev with test case
>>> http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
>>>
>>> JIRA:
>>> https://jbs.oracle.com/bugs/browse/JDK-8014890
>>>
>>> bugs.sun.com
>>> http://bugs.sun.com/view_bug.do?bug_id=8014890
>>>
>>> Testing:
>>> jck, jprt, manual testing
>>>
>>> Note that I also need a sponsor to push in case this change is approved.
> Thanks,
>    Thomas
>
>



From chris.hegarty at oracle.com  Wed Jun 19 09:16:43 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 19 Jun 2013 10:16:43 +0100
Subject: RFR 8017044 & 8017045: anti-delta two changesets
Message-ID: <51C176FB.8010103@oracle.com>

There is uncertainty around the issues that have come up as a result of 
the follow two changesets, I would like to propose we anti-delta them:

   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04
   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/455be95bd1b5

This will afford the responsible engineering team the time to work on 
the issues that these changes brought up, and they can be re-applied at 
a later stage.

Issues filed to track the problems from the above changes:
   8016827: jdk/lambda/LambdaTranslationTest2.java failing
   8016847: Several java/time tests failing with StackOverflowError

The anti-delta changes revert the files to their exact state before the 
changes were applied.

8017044: anti-delta fix for 8015402
	
   Anti-delta the following changeset:
     http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04

   8015402: Lambda metafactory should not attempt to determine bridge
            methods
   Summary: paired with 8013789: Compiler should emit bridges in
            interfaces
   Reviewed-by: twisti
 
src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
   src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
   src/share/classes/java/lang/invoke/LambdaMetafactory.java

8017045: anti-delta fix for 8013789

   Anti-delta the following changeset:
     http://hg.openjdk.java.net/jdk8/tl/langtools/rev/455be95bd1b5

   8013789: Compiler should emit bridges in interfaces
   Summary: paired with 8015402: Lambda metafactory should not attempt
            to determine bridge methods
   Reviewed-by: vromero
   Contributed-by: maurizio.cimadamore at oracle.com
   src/share/classes/com/sun/tools/javac/code/Types.java
   src/share/classes/com/sun/tools/javac/comp/Attr.java
   src/share/classes/com/sun/tools/javac/comp/Check.java
   src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
   src/share/classes/com/sun/tools/javac/comp/TransTypes.java
   src/share/classes/com/sun/tools/javac/tree/JCTree.java
   test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
   test/tools/javac/lambda/methodReference/BridgeMethod.java

-Chris.


From scolebourne at joda.org  Wed Jun 19 09:29:55 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 19 Jun 2013 10:29:55 +0100
Subject: Testing non-OpenJDK code [was Re: RFR : 8016446 : (m) Add override
	forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap,
	TreeMap]
Message-ID: 

On 19 June 2013 08:08, Peter Levart  wrote:
> I'd also like to suggest something. You have made lots of tests that cover
> the functionality of new default methods in Map and other collections
> interfaces which prove the correctness of behaviour when used with
> implementations of those interfaces in JDK. Perhaps It would be wise to
> extend those tests to include some JDK-external implementations that are
> known to pass basic tests, taken for example from Guava or Apache Commons or
> even JDK7. The interactions of default methods with existing methods in
> various implementations of collection interfaces could reveal "bugs" that
> may be on the part of default methods. I'm sure the maintainers of these
> external implementations will do the same, but may be doing that only after
> JDK8 release.

This seems like a good idea, as it would help ensure more generally
that new JDK versions work with key existing libraries.

Stephen


From xuelei.fan at oracle.com  Wed Jun 19 09:34:12 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 19 Jun 2013 09:34:12 +0000
Subject: hg: jdk8/tl/jdk: 7188658: Add possibility to disable client initiated
	renegotiation
Message-ID: <20130619093437.4BA044831C@hg.openjdk.java.net>

Changeset: a76858faad59
Author:    xuelei
Date:      2013-06-19 02:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a76858faad59

7188658: Add possibility to disable client initiated renegotiation
Reviewed-by: weijun, wetmore

! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java



From paul.sandoz at oracle.com  Wed Jun 19 09:45:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 19 Jun 2013 11:45:05 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C1535E.5070105@gmail.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
Message-ID: <09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>


On Jun 19, 2013, at 8:44 AM, Peter Levart  wrote:

> On 06/19/2013 01:13 AM, Mike Duigou wrote:
>> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>> 
>>> On 06/17/13 19:30, Mike Duigou wrote:
>>> 
>>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>> 
>>> Now synched up on my side.
>>> 
>>> -Doug
>>> 
>> 
>> 
>> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.
>> 
>> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java
>> 
>> Mike
> 
> Hi Mike, Remi,
> 
> Since forEach implementation can be taken from default Map.forEach in some implementations of ConcurrentMap, and that implementation is based on entrySet Iterator, isn't it dangerous for this to trigger ConcurrentModificationException in some implementation of ConcurrentMap? I see nothing in the spec. of ConcurrentMap that suggests it's entrySet iterators are never fail-fast. They can be prepared for modifications from other threads (synchronization), but may not tolerate re-entrant calls.
> 
> For example some implementation of (Concurrent)Map could be structurally modified as a result of Map.replace(key, old, new) - imagine a ConcurrentWeakHashMap that expunges stale entries on each call - and forEach iteration may not be prepared to handle such situations.
> 

Or in general when explicitly iterating on the entrySet. 

  for (Map.Entry e : cm.entrySet()) {
    cm.replace(e.getKey(), e.getValue(), newValue);
  }

A concurrent map implementation that provides a fail-fast iterator for in-thread modification is asking for trouble IMHO! Instead i would expect the iterator to be weakly consistent and never throw a CME.

--

This is another little oddity in Map.forEach:

            try {
                k = entry.getKey();
                v = entry.getValue();
            } catch(IllegalStateException ise) {
                throw new ConcurrentModificationException(ise);
            }

I would presume the entries from CconcurrentMap.entrySet would not throw ISEs

Paul.

From thomas.schatzl at oracle.com  Wed Jun 19 09:51:55 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 11:51:55 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C17453.60400@gmail.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <51C17453.60400@gmail.com>
Message-ID: <1371635515.2715.65.camel@cirrus>

Hi Peter,

On Wed, 2013-06-19 at 11:05 +0200, Peter Levart wrote:
> On 06/19/2013 09:17 AM, Thomas Schatzl wrote:
> > Hi,
> >
> > On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
> >> Hi Thomas,
> >>
> >> On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
> >>> Hi all,
> >>>
> >>>     can I have reviews for the following change?
> >>>
> >>> It happens if multiple threads are enqueuing and dequeuing reference
> >>> objects into a reference queue, that Reference objects may be enqueued
> >>> at multiple times.
> >>>
> >>> This is because when java.lang.ref.ReferenceQueue.poll() returns and
> >>> inactivates a Reference object, another thread may just be during
> >>> enqueuing it again.
> >> Are we talking about different queues here? Otherwise both poll() and
> >> enqueue() are using synchronized(lock). I also note that enqueue
> >> synchronizes on the Reference itself, which suggests that poll (actually
> >> reallyPoll) should also be synchronizing on the reference (though we
> >> have a nested lock inversion problem that would need to be solved).
> > This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.
> >
> > Enqueue() and (really-)poll() themselves already synchronize on the
> > "lock" lock to guard modification of the queue, this is safe.
> >
> > The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.
> 
> Hi Thomas,
> 
> It doesn't make a difference between Reference.isEnqueued() and 
> ReferenceQueue.poll(), since there isn't any synchronization between the 

I do not disagree with that, I was just guessing that the
synchronization on the reference was for synchronization between
isEnqueued() and enqueue(). Not poll() and isEnqueued() for the reasons
you mentioned.

> two. So isEnqueued() can still be returning true while another thread 
> has already de-queued the instance. I guess the real use of isEnqueued() 
> method is reliable detection of false -> true transition only.

Probably. 

> I can't see why the isEnqueued() method checks for both (next != null && 
> queue == ENQUEUED). Wouldn't the check for (queue == ENQUEUED) be 
> enough? In that case the Reference.queue field could be made volatile 
> and synchronization on Reference instance removed.

You are right that volatile would be needed in this case.

> While you're at it, the reallyPoll() could optimize the double volatile 
> read from head and only perform it once:

I would be fine with that change, depends on others' opinions. It might
be better to make a different CR for cleanups though.

> 
>      private Reference reallyPoll() {       /* Must hold 
> lock */
>          Reference r = head;
>          if (r != null) {
>              head = (r.next == r) ? null : r.next;
>              r.queue = NULL;
>              r.next = r;
>              queueLength--;
>              if (r instanceof FinalReference) {
>                  sun.misc.VM.addFinalRefCount(-1);
>              }
>              return r;
>          }
>          return null;
>      }
> 
> 
> >
> > Another solution would be to synchronize enqueue() and poll() on the queue itself, and check whether the reference passed to enqueue() is inactive or not (i.e. this check is still needed).
> 
> ReferenceQueue.this and ReferenceQueue.lock are 1<->1. What difference 
> would that make?

None, as I mentioned, for the original issue. Except that it solves the
problem, that if you wanted (as I think has been suggested in the
earlier email) to also synchronize on the reference, which is a bad idea
because of the different order of the nested synchronization. (I am not
sure how also synchronizing on the reference in poll() would improve the
situation too)

It would also obviate the need for the "lock" lock in a next step as
they are 1<->1. But maybe for some other reasons using an explicit lock
object is the preferred way.

Thomas




From forax at univ-mlv.fr  Wed Jun 19 09:53:40 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 19 Jun 2013 11:53:40 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
	<09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
Message-ID: <51C17FA4.6010601@univ-mlv.fr>

On 06/19/2013 11:45 AM, Paul Sandoz wrote:
> On Jun 19, 2013, at 8:44 AM, Peter Levart  wrote:
>
>> On 06/19/2013 01:13 AM, Mike Duigou wrote:
>>> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>>>
>>>> On 06/17/13 19:30, Mike Duigou wrote:
>>>>
>>>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>>>
>>>> Now synched up on my side.
>>>>
>>>> -Doug
>>>>
>>>
>>> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java
>>>
>>> Mike
>> Hi Mike, Remi,
>>
>> Since forEach implementation can be taken from default Map.forEach in some implementations of ConcurrentMap, and that implementation is based on entrySet Iterator, isn't it dangerous for this to trigger ConcurrentModificationException in some implementation of ConcurrentMap? I see nothing in the spec. of ConcurrentMap that suggests it's entrySet iterators are never fail-fast. They can be prepared for modifications from other threads (synchronization), but may not tolerate re-entrant calls.
>>
>> For example some implementation of (Concurrent)Map could be structurally modified as a result of Map.replace(key, old, new) - imagine a ConcurrentWeakHashMap that expunges stale entries on each call - and forEach iteration may not be prepared to handle such situations.
>>
> Or in general when explicitly iterating on the entrySet.
>
>    for (Map.Entry e : cm.entrySet()) {
>      cm.replace(e.getKey(), e.getValue(), newValue);
>    }
>
> A concurrent map implementation that provides a fail-fast iterator for in-thread modification is asking for trouble IMHO! Instead i would expect the iterator to be weakly consistent and never throw a CME.
>
> --
>
> This is another little oddity in Map.forEach:
>
>              try {
>                  k = entry.getKey();
>                  v = entry.getValue();
>              } catch(IllegalStateException ise) {
>                  throw new ConcurrentModificationException(ise);
>              }
>
> I would presume the entries from CconcurrentMap.entrySet would not throw ISEs

Does it worth to override forEach in ConcurrentMap for that ?

>
> Paul.

R?mi



From vicente.romero at oracle.com  Wed Jun 19 10:11:02 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 19 Jun 2013 10:11:02 +0000
Subject: hg: jdk8/tl/langtools: 8006981: javac,
	method toString() of class ...javac.code.Flags doesn't print all the
	flag bits
Message-ID: <20130619101107.D36FF48320@hg.openjdk.java.net>

Changeset: 6d3b33aea370
Author:    vromero
Date:      2013-06-19 11:09 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6d3b33aea370

8006981: javac, method toString() of class ...javac.code.Flags doesn't print all the flag bits
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Check.java



From Alan.Bateman at oracle.com  Wed Jun 19 10:24:07 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jun 2013 11:24:07 +0100
Subject: RFR 8017044 & 8017045: anti-delta two changesets
In-Reply-To: <51C176FB.8010103@oracle.com>
References: <51C176FB.8010103@oracle.com>
Message-ID: <51C186C7.5050007@oracle.com>

On 19/06/2013 10:16, Chris Hegarty wrote:
> There is uncertainty around the issues that have come up as a result 
> of the follow two changesets, I would like to propose we anti-delta them:
>
>   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/989049977d04
>   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/455be95bd1b5
>
> :
>
> The anti-delta changes revert the files to their exact state before 
> the changes were applied.
Just so folks know, we have stability issues at the moment that seem to 
stem from having the bridging in HotSpot at the same time as the 
compiling bridging. Robert has agreed off-list to revert the changes 
until the issues are fully understood. There are 150+ changes queued up 
in jdk8/tl at the moment and so reverting the bridging changes now means 
that the queued up changes can get to master without destabilizing it.

Chris - the revert looks fine to me, thanks for taking this on.

-Alan


From peter.levart at gmail.com  Wed Jun 19 10:35:14 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 12:35:14 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
	<09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
Message-ID: <51C18962.6060302@gmail.com>

On 06/19/2013 11:45 AM, Paul Sandoz wrote:
> On Jun 19, 2013, at 8:44 AM, Peter Levart  wrote:
>
>> On 06/19/2013 01:13 AM, Mike Duigou wrote:
>>> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>>>
>>>> On 06/17/13 19:30, Mike Duigou wrote:
>>>>
>>>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>>>
>>>> Now synched up on my side.
>>>>
>>>> -Doug
>>>>
>>>
>>> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java
>>>
>>> Mike
>> Hi Mike, Remi,
>>
>> Since forEach implementation can be taken from default Map.forEach in some implementations of ConcurrentMap, and that implementation is based on entrySet Iterator, isn't it dangerous for this to trigger ConcurrentModificationException in some implementation of ConcurrentMap? I see nothing in the spec. of ConcurrentMap that suggests it's entrySet iterators are never fail-fast. They can be prepared for modifications from other threads (synchronization), but may not tolerate re-entrant calls.
>>
>> For example some implementation of (Concurrent)Map could be structurally modified as a result of Map.replace(key, old, new) - imagine a ConcurrentWeakHashMap that expunges stale entries on each call - and forEach iteration may not be prepared to handle such situations.
>>
> Or in general when explicitly iterating on the entrySet.
>
>    for (Map.Entry e : cm.entrySet()) {
>      cm.replace(e.getKey(), e.getValue(), newValue);
>    }
>
> A concurrent map implementation that provides a fail-fast iterator for in-thread modification is asking for trouble IMHO! Instead i would expect the iterator to be weakly consistent and never throw a CME.

Sorry, I haven't noticed that the previous version of 
ConcurrentMap.replaceAll has already been using Map.replace(key, old, 
new). I guess that's the only way to guarantee consistency at the 
Map.Entry level in face of concurrent modifications.

Regards, Peter

>
> --
>
> This is another little oddity in Map.forEach:
>
>              try {
>                  k = entry.getKey();
>                  v = entry.getValue();
>              } catch(IllegalStateException ise) {
>                  throw new ConcurrentModificationException(ise);
>              }
>
> I would presume the entries from CconcurrentMap.entrySet would not throw ISEs
>
> Paul.



From chris.hegarty at oracle.com  Wed Jun 19 10:48:23 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 19 Jun 2013 11:48:23 +0100
Subject: RFR 8016324: filter/flatMap pipeline sinks should pass size
	information to downstream sink
In-Reply-To: 
References: 
Message-ID: <51C18C77.6060106@oracle.com>

On 11/06/2013 14:23, Paul Sandoz wrote:
> Hi,
>
> Please review the following patch contributed by Brian Goetz:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
>
> This syncs most of code in the pipeline implementations from lambda to tl (the remaining aspects are to do with Comparator changes which will follow later).
>
> This patch fixes a bug for the filter and flatMap operations, where the corresponding Sink implementations that were incorrectly reporting size to downstream Sinks. A filter or flatMap might result in the output stream containing a different number of elements to that of the input stream so we have to say to a downstream sink "I don't know what my size will be".

Makes sense to me Paul.

-Chris.

> Paul.


From paul.sandoz at oracle.com  Wed Jun 19 10:49:12 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 19 Jun 2013 12:49:12 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C17FA4.6010601@univ-mlv.fr>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
	<09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
	<51C17FA4.6010601@univ-mlv.fr>
Message-ID: <99CDC7EF-3B09-4EEA-B791-C9D7122EB950@oracle.com>

On Jun 19, 2013, at 11:53 AM, Remi Forax  wrote:
>> This is another little oddity in Map.forEach:
>> 
>>             try {
>>                 k = entry.getKey();
>>                 v = entry.getValue();
>>             } catch(IllegalStateException ise) {
>>                 throw new ConcurrentModificationException(ise);
>>             }
>> 
>> I would presume the entries from CconcurrentMap.entrySet would not throw ISEs
> 
> Does it worth to override forEach in ConcurrentMap for that ?
> 

Dunno, i am struggling to work up a strong opinion :-) It seems wrong for ConcurrentMap impls but i just cannot see why any such impls would throw ISEs.

Paul.

From peter.levart at gmail.com  Wed Jun 19 10:48:57 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 12:48:57 +0200
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
	<09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
Message-ID: <51C18C99.2030400@gmail.com>

On 06/19/2013 11:45 AM, Paul Sandoz wrote:
> >>Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.

But only in ConcurrentMap implementations that do override forEach (and 
don't override replaceAll). Can we expect that a ConcurrentMap 
implementations will override both or none in most cases? If it 
overrides both, then defaults don't matter, if it overrides none, then 
what we're left with is only "creation of a capturing BiConsumer lambda" 
overhead for no benefit.

Regards, Peter



From thomas.schatzl at oracle.com  Wed Jun 19 11:20:16 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 13:20:16 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371626704.2715.23.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C0E4F1.3080800@oracle.com>
	<1371626704.2715.23.camel@cirrus>
Message-ID: <1371640816.2715.74.camel@cirrus>

Hi,

On Wed, 2013-06-19 at 09:25 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On Tue, 2013-06-18 at 15:53 -0700, Mandy Chung wrote:
> > Hi Thomas,
> > 
> > Thanks for the detailed analysis.
> > > http://cr.openjdk.java.net/~tschatzl/8014890/webrev/
> > 
> > The fix looks good.  I was able to reproduce the failure with the
> > test case in the bug report running with jdk8 b94 fastdebug build.
> > But the new regression test doesn't fail (I tried solaris-i586).
> > Did it fail on your system?
> > 
> 
> Yes, 100% on my developer machine. I will try to modify it to make it
> fail on more machines (increase number of runs).

With 1000 runs (from 100) I can reproduce on

product/win32, fastdebug+product/linux-x86_64, fastdebug+product/win64,
fastdebug+product/linux-x86, fastdebug+product/solaris-x86, fastdebug
+product/solaris-sparc...

Still a few platforms, i.e. some fastdebug platforms, do not reproduce
the failure. This 

With 100 runs I do not get that many platforms to fail. I will change
the number of iterations to 1000 by default.

When writing the test I was trying to make the test run as quickly as
possible while still showing the issue. I probably went too far in the
"being quick" direction.

I updated the webrev (just the change for the number of iterations from
100 to 1000 in the test program). Its runtime is still only a few
seconds.

Thomas




From dl at cs.oswego.edu  Wed Jun 19 11:23:48 2013
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 19 Jun 2013 07:23:48 -0400
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C18C99.2030400@gmail.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com>
	<09950E05-A398-4DFE-9393-367A79FE3F09@oracle.com>
	<51C18C99.2030400@gmail.com>
Message-ID: <51C194C4.50300@cs.oswego.edu>

On 06/19/13 06:48, Peter Levart wrote:
> On 06/19/2013 11:45 AM, Paul Sandoz wrote:
>> >>Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to
>> use forEach. This trades off the entrySet iterator overhead for creation of a
>> capturing BiConsumer lambda.
>
> But only in ConcurrentMap implementations that do override forEach (and don't
> override replaceAll).

Right. I think the safest choice was the original one.

On 06/19/2013 11:45 AM, Paul Sandoz wrote:
>
> This is another little oddity in Map.forEach:
>
>             try {
>                 k = entry.getKey();
>                 v = entry.getValue();
>             } catch(IllegalStateException ise) {
>                 throw new ConcurrentModificationException(ise);
>             }
>
> I would presume the entries from CconcurrentMap.entrySet would not throw ISEs

There's nothing saying they can't, so this seems harmless enough.

Considering that there are only a few ConcurrentMap implementations
in existence outside of JDK, and that anyone going through the
substantial effort to create one is sure to override defaults
the next chance they get on or before JDK8 release, it seems fine to
aim for the safest correct choices for defaults.

-Doug



From chris.hegarty at oracle.com  Wed Jun 19 12:03:03 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 19 Jun 2013 12:03:03 +0000
Subject: hg: jdk8/tl/langtools: 2 new changesets
Message-ID: <20130619120309.7859E48323@hg.openjdk.java.net>

Changeset: be62183f938a
Author:    chegar
Date:      2013-06-19 11:48 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be62183f938a

8017045: anti-delta fix for 8013789
Reviewed-by: alanb

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! test/tools/javac/lambda/lambdaExpression/LambdaTest6.java
! test/tools/javac/lambda/methodReference/BridgeMethod.java

Changeset: 29dcd6715b04
Author:    chegar
Date:      2013-06-19 13:00 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/29dcd6715b04

Merge

! src/share/classes/com/sun/tools/javac/comp/Check.java



From david.holmes at oracle.com  Wed Jun 19 12:05:37 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Jun 2013 22:05:37 +1000
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371627245.2715.28.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
	<1371627245.2715.28.camel@cirrus>
Message-ID: <51C19E91.1050008@oracle.com>

Hi Thomas,

I think I'm going to need a lot more time to understand this issue 
completely. The synchronization being used seems complex and somewhat 
ill-defined, and also inadequate. I'm not convinced that adding code 
inside a synchronized block really fixes a race condition caused by 
unsynchronized access - but it may well narrow the window significantly.

David

On 19/06/2013 5:34 PM, Thomas Schatzl wrote:
> Hi,
>
>   one more note :)
>
> On Wed, 2013-06-19 at 09:28 +0200, Thomas Schatzl wrote:
>> Hi again,
>>
>>    some correction...
>>
>> On Wed, 2013-06-19 at 09:17 +0200, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2013-06-19 at 12:47 +1000, David Holmes wrote:
>>>> Hi Thomas,
>>>>
>>>> On 19/06/2013 7:08 AM, Thomas Schatzl wrote:
>>>>> Hi all,
>>>>>
>>>>>     can I have reviews for the following change?
>>>>>
>>>>> It happens if multiple threads are enqueuing and dequeuing reference
>>>>> objects into a reference queue, that Reference objects may be enqueued
>>>>> at multiple times.
>>>>>
>>>>> This is because when java.lang.ref.ReferenceQueue.poll() returns and
>>>>> inactivates a Reference object, another thread may just be during
>>>>> enqueuing it again.
>>>>
>>>> Are we talking about different queues here? Otherwise both poll() and
>>>> enqueue() are using synchronized(lock). I also note that enqueue
>>>> synchronizes on the Reference itself, which suggests that poll (actually
>>>> reallyPoll) should also be synchronizing on the reference (though we
>>>> have a nested lock inversion problem that would need to be solved).
>>>
>>> This does not help imo. Still there may be temporary storage containing the original ReferenceQueue reference, and .enqueue() gets called on it with the now inactive Reference.
>>>
>>> Enqueue() and (really-)poll() themselves already synchronize on the
>>> "lock" lock to guard modification of the queue, this is safe.
>>>
>>> The synchronize(r) statement in ReferenceQueue.enqueue() is about synchronization with Reference.isEnqueued() I think. Actually I am not sure whether the synchronization between isEnqueued() and enqueue() makes a difference.
>>
>> This also guards against multiple concurrent calls to enqueue on the
>> same reference - so this statement is needed after all.
>
> Actually, with that patch (e.g. the if (this != r.queue check) return
> false; ) this situation would also be covered I think.
>
> But that's unrelated, sorry.
>
> Thomas
>
>


From chris.hegarty at oracle.com  Wed Jun 19 12:04:25 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 19 Jun 2013 12:04:25 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130619120501.E014A48324@hg.openjdk.java.net>

Changeset: 22337da71eca
Author:    chegar
Date:      2013-06-19 11:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22337da71eca

8017044: anti-delta fix for 8015402
Reviewed-by: alanb

! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java

Changeset: 8bc1b313a082
Author:    chegar
Date:      2013-06-19 13:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bc1b313a082

Merge




From eliasen at mindspring.com  Wed Jun 19 12:27:40 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Wed, 19 Jun 2013 06:27:40 -0600
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large	integers
In-Reply-To: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
Message-ID: <51C1A3BC.7040003@mindspring.com>

On 06/18/2013 06:13 PM, Brian Burkhalter wrote:
> This RFR was initially posted last month:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html
>
>  I hope that this is the final re-post. The issues in question are
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474
> 
> and the webrev as before is at
> 
> http://cr.openjdk.java.net/~bpb/4837946/

   Brian,

   Thanks for pushing this improvement.  As I've said before, I'm more
than willing to put my personal e-mail address on this patch to support
the Karatsuba and Toom-Cook and pow() and radix conversion fixes.  I'll
put my reputation on the line.  You're free to let people e-mail me
personally if their multiplications are incorrect.  I want to support
this.  It makes Java, and pure math, implemented in Java, better.

  If there's a problem, yo, I'll solve it.  (Sorry, I channeled Vanilla
Ice there.)

   After all, I've been publishing many of these improvements for 11+
years, and I'm the person whose e-mail address comes up when someone
searches about these issues.  To be frank, I'm personally involved much
more than Sun/Oracle employees whose e-mail addresses are hidden.  I
field a *lot* of questions about making BigInteger and BigDecimal
faster.  I've helped a lot of people for many years integrate these
changes into their JVMs, which isn't easy.  I try hard.  I have many
examples of fundamental problems in BigInteger being broken for 3+ years
while I've fixed them in my own language within the day.  I am willing
to support this and fix it fast.

   I think my optimizations are simple and obvious;  after all, I posted
a list of links to undergraduate classes who are expected to implement
Karatsuba or Toom-Cook multiplication in a day or a week.  I don't want
to present myself as a genius.  I'm no better than a typical
undergraduate.

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From Alan.Bateman at oracle.com  Wed Jun 19 12:58:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jun 2013 13:58:42 +0100
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
Message-ID: <51C1AB02.7060209@oracle.com>

On 19/06/2013 01:13, Brian Burkhalter wrote:
> This RFR was initially posted last month:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016999.html
>
> I hope that this is the final re-post. The issues in question are
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4646474
>
> and the webrev as before is at
>
> http://cr.openjdk.java.net/~bpb/4837946/
>
> The webrev has been updated to include the correlated JTREG test which was not included in the previous post of the webrev.
>
> As previously mentioned, 4837946 and 7131192 touch some of the same code. I will update the webrev of whichever of these is not approved first to get the correct line numbers, but the review process should only nominally be affected as the actual code changes are disjoint.
>
> Thanks,
>
> Brian
It's great to have this ready to go, it feels that it is years since 
this was first brought up. I can sponsor it and help you get this pushed.

One question on the attribution (so that we have it right). In the 
Contributed-by line then you have Alan Eliasen listed but the @author 
tags have been extended to list Tim Buktu in addition to Alan. Is the 
patch from both Alan and Tim? I ask because I don't see Tim on the OCA list.

-Alan



From aleksey.shipilev at oracle.com  Wed Jun 19 13:56:32 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 19 Jun 2013 17:56:32 +0400
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C19E91.1050008@oracle.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
	<1371627245.2715.28.camel@cirrus> <51C19E91.1050008@oracle.com>
Message-ID: <51C1B890.2020808@oracle.com>

On 06/19/2013 04:05 PM, David Holmes wrote:
> I think I'm going to need a lot more time to understand this issue 
> completely. The synchronization being used seems complex and
> somewhat ill-defined, and also inadequate. I'm not convinced that
> adding code inside a synchronized block really fixes a race condition
> caused by unsynchronized access - but it may well narrow the window
> significantly.

+1. Having spent 30 minutes trying to figure out the synchronization
protocol for R and RQ, I can say that is a haunted part of JDK.

That said, I think the patch fixes the concrete issue. We are
piggybacking on the mutual exclusion on RQ.lock to protect ourselves
from the concurrent mutation of r.queue. The only two places where we
mutate it is RQ.enqueue() and RQ.poll(), both secured with RQ.lock.
Given the r.queue is not volatile, we should also acquire the same lock
while reading r.queue, otherwise races obliterate the reasoning about
the correctness.

With that notion in mind, I start to wonder if we just need to move the
check in enqueue() down into the synchronized(lock), and extend it to
capture NULL:

--- a/src/share/classes/java/lang/ref/ReferenceQueue.java	Mon Jun 17
16:28:22 2013 +0400
+++ b/src/share/classes/java/lang/ref/ReferenceQueue.java	Wed Jun 19
17:53:24 2013 +0400
@@ -56,8 +56,9 @@

     boolean enqueue(Reference r) { /* Called only by
Reference class */
         synchronized (r) {
-            if (r.queue == ENQUEUED) return false;
             synchronized (lock) {
+                if (r.queue == ENQUEUED || r.queue == NULL)
+                    return false;
                 r.queue = ENQUEUED;
                 r.next = (head == null) ? r : head;
                 head = r;

Will it be equivalent to what Thomas is trying to accomplish?

-Aleksey.


From thomas.schatzl at oracle.com  Wed Jun 19 14:09:51 2013
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 19 Jun 2013 16:09:51 +0200
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C1B890.2020808@oracle.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
	<1371627245.2715.28.camel@cirrus> <51C19E91.1050008@oracle.com>
	<51C1B890.2020808@oracle.com>
Message-ID: <1371650991.2715.128.camel@cirrus>

Hi,

On Wed, 2013-06-19 at 17:56 +0400, Aleksey Shipilev wrote:
> On 06/19/2013 04:05 PM, David Holmes wrote:
> > I think I'm going to need a lot more time to understand this issue 
> > completely. The synchronization being used seems complex and
> > somewhat ill-defined, and also inadequate. I'm not convinced that
> > adding code inside a synchronized block really fixes a race condition
> > caused by unsynchronized access - but it may well narrow the window
> > significantly.
> 
> +1. Having spent 30 minutes trying to figure out the synchronization
> protocol for R and RQ, I can say that is a haunted part of JDK.
> 

:) I had the same problem when trying to figure out the code.

> That said, I think the patch fixes the concrete issue. We are
> piggybacking on the mutual exclusion on RQ.lock to protect ourselves
> from the concurrent mutation of r.queue. The only two places where we
> mutate it is RQ.enqueue() and RQ.poll(), both secured with RQ.lock.
> Given the r.queue is not volatile, we should also acquire the same lock
> while reading r.queue, otherwise races obliterate the reasoning about
> the correctness.
>
> With that notion in mind, I start to wonder if we just need to move the
> check in enqueue() down into the synchronized(lock), and extend it to
> capture NULL:
> 
> --- a/src/share/classes/java/lang/ref/ReferenceQueue.java	Mon Jun 17
> 16:28:22 2013 +0400
> +++ b/src/share/classes/java/lang/ref/ReferenceQueue.java	Wed Jun 19
> 17:53:24 2013 +0400
> @@ -56,8 +56,9 @@
> 
>      boolean enqueue(Reference r) { /* Called only by
> Reference class */
>          synchronized (r) {
> -            if (r.queue == ENQUEUED) return false;
>              synchronized (lock) {
> +                if (r.queue == ENQUEUED || r.queue == NULL)
> +                    return false;
>                  r.queue = ENQUEUED;
>                  r.next = (head == null) ? r : head;
>                  head = r;
> 
> Will it be equivalent to what Thomas is trying to accomplish?

Yes, this is equivalent. Instead of checking the separate ENQUEUED and
NULL values I simply used an "r.queue != this" check which would get
both cases. R.queue cannot have other values than ENQUEUED, NULL or the
queue's value set at initialization.

I wanted to minimize the changes for this particular CR.

Thanks,
Thomas




From aleksey.shipilev at oracle.com  Wed Jun 19 14:20:10 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 19 Jun 2013 18:20:10 +0400
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <1371650991.2715.128.camel@cirrus>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
	<1371627245.2715.28.camel@cirrus> <51C19E91.1050008@oracle.com>
	<51C1B890.2020808@oracle.com> <1371650991.2715.128.camel@cirrus>
Message-ID: <51C1BE1A.5030602@oracle.com>

On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
>> With that notion in mind, I start to wonder if we just need to move the
>> check in enqueue() down into the synchronized(lock), and extend it to
>> capture NULL:
>>
>> --- a/src/share/classes/java/lang/ref/ReferenceQueue.java	Mon Jun 17
>> 16:28:22 2013 +0400
>> +++ b/src/share/classes/java/lang/ref/ReferenceQueue.java	Wed Jun 19
>> 17:53:24 2013 +0400
>> @@ -56,8 +56,9 @@
>>
>>      boolean enqueue(Reference r) { /* Called only by
>> Reference class */
>>          synchronized (r) {
>> -            if (r.queue == ENQUEUED) return false;
>>              synchronized (lock) {
>> +                if (r.queue == ENQUEUED || r.queue == NULL)
>> +                    return false;
>>                  r.queue = ENQUEUED;
>>                  r.next = (head == null) ? r : head;
>>                  head = r;
>>
>> Will it be equivalent to what Thomas is trying to accomplish?
> 
> Yes, this is equivalent. Instead of checking the separate ENQUEUED and
> NULL values I simply used an "r.queue != this" check which would get
> both cases. R.queue cannot have other values than ENQUEUED, NULL or the
> queue's value set at initialization.

Yeah, for my taste, explicitly checking for ENQUEUED || NULL declares
the intent more clearly. YMMV, though. I'm OK with plumbing the hole...
your style. :)

-Aleksey.




From peter.levart at gmail.com  Wed Jun 19 14:23:02 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 16:23:02 +0200
Subject: 7122142 : (ann) Race condition between isAnnotationPresent and
	getAnnotations
Message-ID: <51C1BEC6.1080308@gmail.com>

Hi,

Since the bulk of changes to annotations and reflection have stabilized, 
I'm bringing up a re-based batch that I have proposed some months ago:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html

The patch fixes a deadlock situation described in:

     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122142

...and also a logical inconsistency when parsing mutually-recursive 
runtime annotations combined with change of @Retention and separate 
compilation (described in above thread).

Here's the webrev for the patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.01/

The deadlock occurs because two object monitors are tried to be acquired 
by two threads in different order. One object monitor is represented by 
static synchronized AnnotationType.getInstance(Class) method, the other 
is synchronized Class.initAnnotationsIfNecessary() instance method. 
There are various scenarios where these two methods can be entered by 
different threads in opposite order and for same j.l.Class instance.

AnnotationType.getInstance(Class) is synchronized, because it guards 
access to j.l.Class.annotationType field while AnnotationType instance 
for particular Class is being constructed. AnnotationType instance is 
published via Class.annotationType field in the middle of AnnotationType 
constructor so that annotation's meta-annotations can be obtained after 
that point as the final act of AnnotationType construction. While 
meta-annotations are being obtained, other meta-annotations (besides 
standard @Retention and @Inhereted) can be parsed for the 1st time, 
which triggers AnnotationType.getInstance(Class) call for those 
meta-annotation classes. If such meta-annotation classes are mutually 
recursive with the annotation class that AnnotationType is being 
constructed for, AnnotationType.getInstance(Class) can be re-entered for 
the same annotation class. To prevent infinite recursion, 
half-constructed AnnotationType instance is published in the middle of 
the AnnotationType constructor. Synchronized AnnotationType.getInstance 
prevents other threads to interfere while AnnotationType is being 
constructed, but allows re-entrancy from the same thread.

The presented patch solves this situation by removing the synchronized 
keyword from AnnotationType.getInstance(Class) static method, Making 
this method contention-free as a benefit. All other changes are a result 
of that removal:
- AnnotationType class is made immutable (all fields final)
- The instance is published only after the constructor for 
AnnotationType returns (in AnnotationType.getInstance() method). Because 
caching is idempotent and AnnotationType object is immutable, no 
synchronization is attempted and not even Class.annotationType filed is 
made volatile.
- To prevent infinite recursion while obtaining meta-annotations, the 
process of obtaining them was redesigned. Instead of calling 
getAnnotation(Retention.class) or isAnnotationPresent(Inherited.class) 
which triggers parsing of other meta-annotations too, special method was 
added to AnnotationParser which is used solely to parse select 
meta-annotations in the AnnotationType constructor and which does not 
need to evaluate AnnotationType.getInstance() method, thus making this 
parsing method recursion-free.

The benefit of not recursing while obtaining meta-annotations is also 
more correct logic when obtaining mutualy-recursive annotations for 
which one of them was changed (@Retention: RUNTIME -> CLASS) and 
separately compiled.

This patch is one angle of attack for bug 7122142. The other is, off 
course, removing the other synchronized keyword (on 
Class.initAnnotationsIfNecessary()). I'm planning to do that too, but in 
a more straight-forward manner.

Regards, Peter



From brian.burkhalter at oracle.com  Wed Jun 19 14:46:14 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Jun 2013 07:46:14 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: <51C1AB02.7060209@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
	<51C1AB02.7060209@oracle.com>
Message-ID: <7B28454C-D74F-43F3-8568-813D581471B8@oracle.com>

I think Tim is involved only in phases 3 and 4 of the BigInteger improvements so we could remove him as author for now. His OCA status should however be cleared up soon as I am hoping to move onto phase 3 before long.

Brian

On Jun 19, 2013, at 5:58 AM, Alan Bateman wrote:

> One question on the attribution (so that we have it right). In the Contributed-by line then you have Alan Eliasen listed but the @author tags have been extended to list Tim Buktu in addition to Alan. Is the patch from both Alan and Tim? I ask because I don't see Tim on the OCA list.



From weijun.wang at oracle.com  Wed Jun 19 14:53:27 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 19 Jun 2013 22:53:27 +0800
Subject: Attributions (was Re: Final RFR 4837946: Faster multiplication and
	exponentiation of large integers)
In-Reply-To: <51C1AB02.7060209@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
	<51C1AB02.7060209@oracle.com>
Message-ID: <51C1C5E7.9090605@oracle.com>



On 6/19/2013 8:58 PM, Alan Bateman wrote:
>
> One question on the attribution (so that we have it right). In the
> Contributed-by line then you have Alan Eliasen listed but the @author
> tags have been extended to list Tim Buktu in addition to Alan. Is the
> patch from both Alan and Tim? I ask because I don't see Tim on the OCA
> list.

Is it possible for jcheck to check non- at oracle.com Contributed-by names 
against OCA?

Thanks
Max

>
> -Alan
>


From brian.burkhalter at oracle.com  Wed Jun 19 15:14:48 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Jun 2013 08:14:48 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
Message-ID: 

I have updated this webrev per Martin's comments and removed Tim from the @author list. If the latter is incorrect, please let me know.

Brian

On Jun 18, 2013, at 5:13 PM, Brian Burkhalter wrote:

> the webrev as before is at
> 
> http://cr.openjdk.java.net/~bpb/4837946/



From daniel.fuchs at oracle.com  Wed Jun 19 15:31:53 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 19 Jun 2013 17:31:53 +0200
Subject: RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
Message-ID: <51C1CEE9.9010200@oracle.com>

Hi,

Please find below a proposed fix for:

7184195 - java.util.logging.Logger.getGlobal().info()
           doesn't log without configuration

Jim who was the original evaluator of this bug find out
that the root cause of the issue was that LogManager hadn't been
initialized yet, and therefore the global Logger returned had its
manager instance 'null' - and more to the point - had no configuration
since the configuration is established by the LogManager.

The fix proposed is simple. In getGlobal() we check whether
the 'manager' variable is null - and if it is, we initialize it
by calling LogManager.getLogManager().
This is a pattern which is already present at other places in
the Logger.java class file.



However - initialization of LogManager has proved to be fragile
in the past - in particular wrt deadlocks between Logger and
LogManager caused by circular class initialization.

Therefore, I have added two test files TestGetGlobal.java and
TestGetGlobal2.java which try to trigger such deadlocks by
calling Logger.getGlobal()
or Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) before the
LogManager class is initialized.

The tests have a bunch of @run line trying to do so with
different configurations, including by using custom LogManager
subclasses, with and without a security manager on.

I have seen no issue so far.

best regards,

-- daniel


From mike.duigou at oracle.com  Wed Jun 19 15:44:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 08:44:45 -0700
Subject: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap,
	Hashtable, IdentityHashMap, WeakHashMap, TreeMap
In-Reply-To: <51C15904.4050806@gmail.com>
References: <5CEB3C65-C6AF-4F4B-8C21-9D5D37F0BD2A@oracle.com>
	<51B8FB12.2090901@univ-mlv.fr>
	<081CE784-0948-4914-B4F4-E22F82D7725E@oracle.com>
	
	
	
	<51C0504C.4060700@cs.oswego.edu>
	
	<51C1535E.5070105@gmail.com> <51C15904.4050806@gmail.com>
Message-ID: <0FBEFE4F-1EEB-44FA-83EC-313DEB9641CA@oracle.com>

I certainly have been curious as to how well our defaults work for the non-OpenJDK collections implementations but unfortunately haven't had time to pursue testing them yet. We plan to run a broader selection of software with JDK8 as we progress to release and testing with Guava, Apache Collections and Goldman Sachs collections are certainly part of that. In the meantime we are definitely interested in hearing any reports of issues or performance concerns.

Mike

On Jun 19 2013, at 00:08 , Peter Levart wrote:

> On 06/19/2013 08:44 AM, Peter Levart wrote:
>> On 06/19/2013 01:13 AM, Mike Duigou wrote:
>>> On Jun 18 2013, at 05:19 , Doug Lea wrote:
>>> 
>>>> On 06/17/13 19:30, Mike Duigou wrote:
>>>> 
>>>>> I had to add the improved default for ConcurrentMap which was present in the lambda repo in order to have correct behaviour. Since getOrDefault is already in ConcurrentMap I will include this but we have to be careful when we do a jsr 166 syncup to make sure that the defaults don't get lost.
>>>>> 
>>>> Now synched up on my side.
>>>> 
>>>> -Doug
>>>> 
>>> 
>>> 
>>> Per a suggestion from Remi I updated the ConcurrentMap.replaceAll default to use forEach. This trades off the entrySet iterator overhead for creation of a capturing BiConsumer lambda.
>>> 
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/raw-diff/1f7cbe4829fe/src/share/classes/java/util/concurrent/ConcurrentMap.java 
>>> 
>>> Mike
>> 
>> Hi Mike, Remi,
>> 
>> Since forEach implementation can be taken from default Map.forEach in some implementations of ConcurrentMap, and that implementation is based on entrySet Iterator, isn't it dangerous for this to trigger ConcurrentModificationException in some implementation of ConcurrentMap? I see nothing in the spec. of ConcurrentMap that suggests it's entrySet iterators are never fail-fast. They can be prepared for modifications from other threads (synchronization), but may not tolerate re-entrant calls.
>> 
>> For example some implementation of (Concurrent)Map could be structurally modified as a result of Map.replace(key, old, new) - imagine a ConcurrentWeakHashMap that expunges stale entries on each call - and forEach iteration may not be prepared to handle such situations.
>> 
>> Regards, Peter
>> 
> 
> Hi Mike,
> 
> I'd also like to suggest something. You have made lots of tests that cover the functionality of new default methods in Map and other collections interfaces which prove the correctness of behaviour when used with implementations of those interfaces in JDK. Perhaps It would be wise to extend those tests to include some JDK-external implementations that are known to pass basic tests, taken for example from Guava or Apache Commons or even JDK7. The interactions of default methods with existing methods in various implementations of collection interfaces could reveal "bugs" that may be on the part of default methods. I'm sure the maintainers of these external implementations will do the same, but may be doing that only after JDK8 release.
> 
> Regards, Peter
> 



From mike.duigou at oracle.com  Wed Jun 19 15:49:32 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 08:49:32 -0700
Subject: RFR 8016324: filter/flatMap pipeline sinks should pass size
	information to downstream sink
In-Reply-To: 
References: 
Message-ID: 

Looks good.

Mike

On Jun 11 2013, at 06:23 , Paul Sandoz wrote:

> Hi,
> 
> Please review the following patch contributed by Brian Goetz:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
> 
> This syncs most of code in the pipeline implementations from lambda to tl (the remaining aspects are to do with Comparator changes which will follow later). 
> 
> This patch fixes a bug for the filter and flatMap operations, where the corresponding Sink implementations that were incorrectly reporting size to downstream Sinks. A filter or flatMap might result in the output stream containing a different number of elements to that of the input stream so we have to say to a downstream sink "I don't know what my size will be".
> 
> Paul.



From mike.duigou at oracle.com  Wed Jun 19 15:57:31 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 08:57:31 -0700
Subject: RFR 8016308: Updates to j.u.stream.Node/Nodes
In-Reply-To: <6F6B4E32-9FA3-4CD1-914A-E8DBE8C47250@oracle.com>
References: <6F6B4E32-9FA3-4CD1-914A-E8DBE8C47250@oracle.com>
Message-ID: 

Looks fine.

On Jun 11 2013, at 03:12 , Paul Sandoz wrote:

> Hi
> 
> Please review the following patch:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/
> 
> This syncs up java.util.stream.Node/Nodes from the lambda repo to the tl repo. The main changes are related to reducing the code for primitive specializations. There are some temporary functions added to SliceOps.SliceTask, and changes to SliceOps, specifically to improve out of memory issues with infinite or large streams, will follow later on (which incidentally will also use the Node.truncate methods).
> 
> This patch is based off the following patch that was previously sent out for review:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8016251-spinedBuffer-splitr/webrev/
> 
> Paul.



From mike.duigou at oracle.com  Wed Jun 19 15:59:07 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 08:59:07 -0700
Subject: RFR 8012987: Optimizations for Stream.limit/substream
In-Reply-To: <846D60F7-4D7D-48E2-9409-84DAB76F01AD@oracle.com>
References: <846D60F7-4D7D-48E2-9409-84DAB76F01AD@oracle.com>
Message-ID: 

Looks fine. I would encourage you to test and push all four of these together.

Mike

On Jun 14 2013, at 05:40 , Paul Sandoz wrote:

> Hi,
> 
> This patch implements optimizations for the limit/substream operations when input to those operations have certain properties (corresponding to known size or unordered) which helps to avoid out of memory issues (not all, we still have some more work to do).
> 
> The {Xxx}/Stream.generate methods have been modified to generate a known infinite stream of unordered elements. Previously an ordered known infinite stream of elements was generated, making it particularly prone to OOMEs. 
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8012987-slice/webrev/
> 
> -
> 
> This is based on the following in order, still requiring reviews (hint hint):
> 
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8016308-Node/webrev/
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8016324-pipelines/webrev/
> http://cr.openjdk.java.net/~psandoz/tl/JDK-8016455-stream-tests/webrev/
> 
> Plus:
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/  (Note this is not rebased in this version, but is in my patch queue)
> 
> Paul.
> 



From Alan.Bateman at oracle.com  Wed Jun 19 16:16:46 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jun 2013 17:16:46 +0100
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large integers
In-Reply-To: 
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
	
Message-ID: <51C1D96E.1030303@oracle.com>

On 19/06/2013 16:14, Brian Burkhalter wrote:
> I have updated this webrev per Martin's comments and removed Tim from the @author list. If the latter is incorrect, please let me know.
>
> Brian
>
Thanks, I think we are good now.

-Alan


From alan.bateman at oracle.com  Wed Jun 19 16:14:17 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 19 Jun 2013 16:14:17 +0000
Subject: hg: jdk8/tl/jdk: 4837946: Faster multiplication and exponentiation of
	large integers; ...
Message-ID: <20130619161429.A5D994832B@hg.openjdk.java.net>

Changeset: 9b802d99cb52
Author:    bpb
Date:      2013-06-19 08:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b802d99cb52

4837946: Faster multiplication and exponentiation of large integers
4646474: BigInteger.pow() algorithm slow in 1.4.0
Summary: Implement Karatsuba and 3-way Toom-Cook multiplication as well as exponentiation using Karatsuba and Toom-Cook squaring.
Reviewed-by: alanb, bpb, martin
Contributed-by: Alan Eliasen 

! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/BigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java



From chris.hegarty at oracle.com  Wed Jun 19 16:33:22 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 19 Jun 2013 16:33:22 +0000
Subject: hg: jdk8/tl/jdk: 6 new changesets
Message-ID: <20130619163436.9FC6248332@hg.openjdk.java.net>

Changeset: e7ece2dbdc70
Author:    sla
Date:      2013-06-10 11:33 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7ece2dbdc70

8005008: Add Java Flight Recorder Phase II
Reviewed-by: erikj
Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova 

! make/com/oracle/jfr/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/mapfiles/libjfr/mapfile-vers
! makefiles/mapfiles/libjli/mapfile-vers
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 1f855dd74077
Author:    amurillo
Date:      2013-06-14 07:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f855dd74077

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/CreateJars.gmk

Changeset: c3087d966f1f
Author:    chegar
Date:      2013-06-19 11:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3087d966f1f

Merge

! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: a5735e6d6616
Author:    chegar
Date:      2013-06-19 11:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5735e6d6616

Merge


Changeset: a9ad5ac3430b
Author:    chegar
Date:      2013-06-19 15:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9ad5ac3430b

8017057: More ProblemList.txt updates (6/2013)
Reviewed-by: alanb

! test/ProblemList.txt

Changeset: 8fd1e39b1c2b
Author:    chegar
Date:      2013-06-19 17:32 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fd1e39b1c2b

Merge




From henry.jen at oracle.com  Wed Jun 19 17:29:54 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 19 Jun 2013 10:29:54 -0700
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51BCF8B6.4050307@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
Message-ID: <51C1EA92.9010102@oracle.com>

A ping to wake up the thread, there is a minor update regard the use of
@apiNote since last email.

Thanks in advance for reviewing.

Cheers,
Henry


On 06/15/2013 04:28 PM, Henry Jen wrote:
> Reflecting feedbacks received so far, please see
> 
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/webrev/
> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/specdiff
> 
> Cheers,
> Henry
> 
> 
> On 06/11/2013 02:04 PM, Henry Jen wrote:
>> Hi,
>>
>> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
>>
>> Highlight of changes,
>>
>> - Comparators class is now only package-private implementations. The
>> public static methods have been move to other arguably more appropriate
>> places, mostly in Comparator.
>>
>> - Comparator.reverseOrder() is renamed to Comparator.reversed()
>>
>> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
>> wrap up a comparator to be null-friendly.
>>
>> To see the API changes, found the specdiff at
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
>>
>> Cheers,
>> Henry
>>
> 



From brian.burkhalter at oracle.com  Wed Jun 19 17:56:07 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Jun 2013 10:56:07 -0700
Subject: Final RFR 4837946: Faster multiplication and exponentiation of
	large	integers
In-Reply-To: <51C1A3BC.7040003@mindspring.com>
References: <418FEE3B-9DFF-43E0-ADCB-916D40BAA06A@oracle.com>
	<51C1A3BC.7040003@mindspring.com>
Message-ID: <69C8CE5D-AD31-4848-AE1B-EDE3723F79EB@oracle.com>

Alan,

On Jun 19, 2013, at 5:27 AM, Alan Eliasen wrote:

> Thanks for pushing this improvement.  As I've said before, I'm more
> than willing to put my personal e-mail address on this patch to support
> the Karatsuba and Toom-Cook and pow() and radix conversion fixes.  I'll
> put my reputation on the line.  You're free to let people e-mail me
> personally if their multiplications are incorrect.  I want to support
> this.  It makes Java, and pure math, implemented in Java, better.
> 
>  If there's a problem, yo, I'll solve it.  (Sorry, I channeled Vanilla
> Ice there.)
> 
>   After all, I've been publishing many of these improvements for 11+
> years, and I'm the person whose e-mail address comes up when someone
> searches about these issues.  To be frank, I'm personally involved much
> more than Sun/Oracle employees whose e-mail addresses are hidden.  I
> field a *lot* of questions about making BigInteger and BigDecimal
> faster.  I've helped a lot of people for many years integrate these
> changes into their JVMs, which isn't easy.  I try hard.

Your efforts are appreciated, for sure.

> I have many examples of fundamental problems in BigInteger being broken for 3+ years

If there are still extant problems which have no issue on file, then a bug report should be submitted for each.

> while I've fixed them in my own language within the day.  I am willing
> to support this and fix it fast.
> 
>   I think my optimizations are simple and obvious;  after all, I posted
> a list of links to undergraduate classes who are expected to implement
> Karatsuba or Toom-Cook multiplication in a day or a week.  I don't want
> to present myself as a genius.  I'm no better than a typical
> undergraduate.

I concur that the optimizations I've reviewed so far seem to be fairly straightforward.

As for bugs for problems, enhancement requests for any new features or performance improvements in the numerics area should have corresponding issues on file. This will be of particular importance in planning for JDK 9.

Thanks,

Brian

From mandy.chung at oracle.com  Wed Jun 19 18:25:12 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Jun 2013 11:25:12 -0700
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51C1733A.7020008@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
	<51C1733A.7020008@oracle.com>
Message-ID: <51C1F788.7090707@oracle.com>

On 6/19/13 2:00 AM, Daniel Fuchs wrote:
> On 6/13/13 10:05 PM, Mandy Chung wrote:
>> Daniel,
>>
>> I wonder what the list of logger names (loggers1 and loggers2) returned
>> by LoggingMXBean contains and that may include loggers in the running VM
>> other than the ones created and kept a strong reference by the test. In
>> other words,  would it be possible for the running VM that has loggers
>> that are not created by the test and got GC'ed?
>
> Hi Mandy,
>
> I have added a System.out.println to print the list of logger names.
> By running jtreg on my machine I could see that this list does contain
> system logger names (mostly JMX loggers).
> I believe those loggers are strongly referenced by JMX.
> Other than those I could see "" and "global".
>
> 
>
> However - since this seems to be an intermittent failure - maybe the
> logger that was causing the problem had already been gc'ed before
> getLoggerNames() and therefore didn't appear in this list.
> The test would fail when that 'transient' logger appears in the
> list but is gc'ed before getLoggerLevel() is called.
>
> Anyway - it's possible that some platform class
> is calling:
>    Logger log = Logger.getLogger();
>    if (log.isLoggable()) {...}
> without keeping a strong reference to the logger in the class.
>
> In that case I guess it would be possible for that 
> to appear transiently in the logger's name list - and be gc'ed
> just after...
>

Is this test running in othervm mode?  or samevm mode?   I would think 
there is no logger created when checkAttributes is being called.

The checkAttributes method is intended to verify LoggingMXBean and 
PlatformLoggingMXBean are functionally equivalent.  I would suggest to 
just check the two loggers created by this test and simply skip others  
at the beginning of the loop to make the test reliable. What you have is 
okay to print out warning but I think it's not necessary in the fix.  In 
addition, the check on mxbean1.getParentLoggerName != 
mxbean2.getParentLoggerName may also run into this race when a logger 
being gc'ed.

Mandy



From chris.hegarty at oracle.com  Wed Jun 19 16:30:17 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 19 Jun 2013 16:30:17 +0000
Subject: hg: jdk8/tl/hotspot: 5 new changesets
Message-ID: <20130619163028.6426548330@hg.openjdk.java.net>

Changeset: d0add7016434
Author:    amurillo
Date:      2013-06-07 09:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0add7016434

8016078: new hotspot build - hs25-b37
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: f2110083203d
Author:    sla
Date:      2013-06-10 11:30 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2110083203d

8005849: JEP 167: Event-Based JVM Tracing
Reviewed-by: acorn, coleenp, sla
Contributed-by: Karen Kinnear , Bengt Rutisson , Calvin Cheung , Erik Gahlin , Erik Helin , Jesper Wilhelmsson , Keith McGuigan , Mattias Tobiasson , Markus Gronlund , Mikael Auno , Nils Eliasson , Nils Loodin , Rickard Backman , Staffan Larsen , Stefan Karlsson , Yekaterina Kantserova 

! make/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/minimal1.make
! make/bsd/makefiles/top.make
+ make/bsd/makefiles/trace.make
! make/bsd/makefiles/vm.make
! make/defs.make
! make/excludeSrc.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/minimal1.make
! make/linux/makefiles/top.make
+ make/linux/makefiles/trace.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/top.make
+ make/solaris/makefiles/trace.make
! make/solaris/makefiles/vm.make
! make/windows/build.make
! make/windows/create_obj_files.sh
! make/windows/makefiles/generated.make
! make/windows/makefiles/projectcreator.make
+ make/windows/makefiles/trace.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! src/cpu/sparc/vm/frame_sparc.cpp
! src/cpu/x86/vm/frame_x86.cpp
! src/os/bsd/vm/osThread_bsd.hpp
! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/os_bsd.hpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/linux/vm/osThread_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/solaris/vm/osThread_solaris.cpp
! src/os/solaris/vm/osThread_solaris.hpp
! src/os/solaris/vm/os_share_solaris.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/windows/vm/os_windows.cpp
! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp
! src/os_cpu/bsd_x86/vm/thread_bsd_x86.hpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp
! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp
! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp
! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp
! src/share/tools/ProjectCreator/BuildConfig.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! 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/evacuationInfo.hpp
! 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/g1GCPhaseTimes.hpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp
+ src/share/vm/gc_implementation/g1/g1YCTypes.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
+ src/share/vm/gc_implementation/shared/copyFailedInfo.hpp
+ src/share/vm/gc_implementation/shared/gcHeapSummary.hpp
+ src/share/vm/gc_implementation/shared/gcTimer.cpp
+ src/share/vm/gc_implementation/shared/gcTimer.hpp
+ src/share/vm/gc_implementation/shared/gcTrace.cpp
+ src/share/vm/gc_implementation/shared/gcTrace.hpp
+ src/share/vm/gc_implementation/shared/gcTraceSend.cpp
+ src/share/vm/gc_implementation/shared/gcTraceTime.cpp
+ src/share/vm/gc_implementation/shared/gcTraceTime.hpp
+ src/share/vm/gc_implementation/shared/gcWhen.hpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/gc_implementation/shared/markSweep.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.cpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
+ src/share/vm/gc_interface/allocTracer.cpp
+ src/share/vm/gc_interface/allocTracer.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/gc_interface/collectedHeap.inline.hpp
! src/share/vm/gc_interface/gcCause.cpp
! src/share/vm/gc_interface/gcCause.hpp
+ src/share/vm/gc_interface/gcName.hpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/defNewGeneration.cpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genMarkSweep.cpp
! src/share/vm/memory/generation.cpp
! src/share/vm/memory/heapInspection.cpp
! src/share/vm/memory/heapInspection.hpp
+ src/share/vm/memory/klassInfoClosure.hpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
+ src/share/vm/memory/referenceProcessorStats.hpp
+ src/share/vm/memory/referenceType.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/matcher.cpp
+ src/share/vm/opto/phasetype.hpp
! src/share/vm/precompiled/precompiled.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiGen.java
! src/share/vm/prims/jvmtiImpl.cpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/frame.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/objectMonitor.cpp
! src/share/vm/runtime/objectMonitor.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/perfData.hpp
! src/share/vm/runtime/stubRoutines.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/task.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/timer.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vmThread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticArgument.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/memBaseline.cpp
+ src/share/vm/trace/noTraceBackend.hpp
+ src/share/vm/trace/trace.dtd
+ src/share/vm/trace/trace.xml
+ src/share/vm/trace/traceBackend.hpp
+ src/share/vm/trace/traceDataTypes.hpp
+ src/share/vm/trace/traceEvent.hpp
+ src/share/vm/trace/traceEventClasses.xsl
+ src/share/vm/trace/traceEventIds.xsl
- src/share/vm/trace/traceEventTypes.hpp
! src/share/vm/trace/traceMacros.hpp
+ src/share/vm/trace/traceStream.hpp
+ src/share/vm/trace/traceTime.hpp
+ src/share/vm/trace/traceTypes.xsl
+ src/share/vm/trace/tracetypes.xml
! src/share/vm/trace/tracing.hpp
+ src/share/vm/trace/xinclude.mod
+ src/share/vm/trace/xsl_util.xsl
! src/share/vm/utilities/globalDefinitions.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 69689078dff8
Author:    amurillo
Date:      2013-06-13 23:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69689078dff8

Merge

- src/share/vm/trace/traceEventTypes.hpp

Changeset: 5d65c078cd0a
Author:    amurillo
Date:      2013-06-13 23:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d65c078cd0a

Added tag hs25-b37 for changeset 69689078dff8

! .hgtags

Changeset: 3a0774193f71
Author:    chegar
Date:      2013-06-19 11:02 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a0774193f71

Merge

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jvm.cpp
- src/share/vm/trace/traceEventTypes.hpp



From Alan.Bateman at oracle.com  Wed Jun 19 18:54:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jun 2013 19:54:28 +0100
Subject: 7122142 : (ann) Race condition between isAnnotationPresent and
	getAnnotations
In-Reply-To: <51C1BEC6.1080308@gmail.com>
References: <51C1BEC6.1080308@gmail.com>
Message-ID: <51C1FE64.3020000@oracle.com>

On 19/06/2013 15:23, Peter Levart wrote:
> Hi,
>
> Since the bulk of changes to annotations and reflection have 
> stabilized, I'm bringing up a re-based batch that I have proposed some 
> months ago:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html 
>
>
> :
>
> This patch is one angle of attack for bug 7122142. The other is, off 
> course, removing the other synchronized keyword (on 
> Class.initAnnotationsIfNecessary()). I'm planning to do that too, but 
> in a more straight-forward manner.
>
> Regards, Peter
>
Thank you for coming back to this.

I've looked over the webrev and the approach looks good to me. Joel 
might want to look at this too. Do you think you could include a test 
(as we try to include a test with all fixes if we can)?

It would be good to remove the synchronizaiton on 
initAnnotationsIfNecessary too, but one step as time (and smaller 
changes are always easier to discuss).

-Alan




From peter.levart at gmail.com  Wed Jun 19 19:16:25 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Jun 2013 21:16:25 +0200
Subject: 7122142 : (ann) Race condition between isAnnotationPresent and
	getAnnotations
In-Reply-To: <51C1FE64.3020000@oracle.com>
References: <51C1BEC6.1080308@gmail.com> <51C1FE64.3020000@oracle.com>
Message-ID: <51C20389.8040803@gmail.com>


On 06/19/2013 08:54 PM, Alan Bateman wrote:
> On 19/06/2013 15:23, Peter Levart wrote:
>> Hi,
>>
>> Since the bulk of changes to annotations and reflection have 
>> stabilized, I'm bringing up a re-based batch that I have proposed 
>> some months ago:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014203.html 
>>
>>
>> :
>>
>> This patch is one angle of attack for bug 7122142. The other is, off 
>> course, removing the other synchronized keyword (on 
>> Class.initAnnotationsIfNecessary()). I'm planning to do that too, but 
>> in a more straight-forward manner.
>>
>> Regards, Peter
>>
> Thank you for coming back to this.
>
> I've looked over the webrev and the approach looks good to me. Joel 
> might want to look at this too. Do you think you could include a test 
> (as we try to include a test with all fixes if we can)?

Hi Alan,

I'll do the tests for both issues. The 1st (deadlock) will be 
straightforward (I think). But the second requires two versions of 
source file for single class. The 1st version is compiled with the test 
and the 2nd version is compiled separately and used to run the test (to 
simulate separate compilation). Do you happen to know if something like 
that has already been done in some JDK test or how to approach writing 
such test (whether there's already any infrastructure built that might 
support such tests)?

>
> It would be good to remove the synchronizaiton on 
> initAnnotationsIfNecessary too, but one step as time (and smaller 
> changes are always easier to discuss).

One step at a time, right. I actually thought that to be a separate, 
unrelated patch that just happens to solve the same bug, but it also 
solves the other one:

8011940 : java.lang.Class.getAnnotations() always enters synchronized method


Regards, Peter


>
> -Alan
>
>



From brian.burkhalter at oracle.com  Wed Jun 19 19:58:25 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Jun 2013 12:58:25 -0700
Subject: RFR 4641897: Faster string conversion of large integers
Message-ID: 

Continuing on from this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html

here is a new Request for Review, this time for

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897

The webrev is here

http://cr.openjdk.java.net/~bpb/4641897/

The code changes have been reviewed by me and regression tests have been run on my development machine including the updated test which is in the webrev. Performance testing has been performed only insofar as to verify improvement at bit lengths much larger than the algorithm crossover threshold with the understanding that, as for 4837946 and 4646474, the threshold is subject to adjustment pending performance evaluation on a mix of platforms.

Thanks,

Brian

From dan.xu at oracle.com  Wed Jun 19 20:01:06 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Wed, 19 Jun 2013 20:01:06 +0000
Subject: hg: jdk8/tl/jdk: 8016592: Clean-up Javac Overrides Warnings In
	javax/management/NotificationBroadcasterSupport.java
Message-ID: <20130619200118.EFC0F48347@hg.openjdk.java.net>

Changeset: f6d72c4f6bf1
Author:    dxu
Date:      2013-06-19 13:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f6d72c4f6bf1

8016592: Clean-up Javac Overrides Warnings In javax/management/NotificationBroadcasterSupport.java
Summary: Add hashCode() methods to ListenerInfo and WildcardListenerInfo classes
Reviewed-by: dfuchs, alanb, sjiang, chegar

! src/share/classes/javax/management/NotificationBroadcasterSupport.java



From kurchi.subhra.hazra at oracle.com  Wed Jun 19 20:53:48 2013
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Wed, 19 Jun 2013 20:53:48 +0000
Subject: hg: jdk8/tl/jdk: 8016576: Overrides warnings in jdi and jconsole
Message-ID: <20130619205400.C93AF48349@hg.openjdk.java.net>

Changeset: de6b93fd6d23
Author:    khazra
Date:      2013-06-19 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de6b93fd6d23

8016576: Overrides warnings in jdi and jconsole
Summary: Implement hashCode() in classes emitting warnings
Reviewed-by: alanb, chegar

! src/share/classes/com/sun/tools/jdi/SDE.java
! src/share/classes/sun/tools/jconsole/inspector/XObject.java



From kurchi.subhra.hazra at oracle.com  Wed Jun 19 21:03:09 2013
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Wed, 19 Jun 2013 21:03:09 +0000
Subject: hg: jdk8/tl/jdk: 8016698: Cleanup overrides warning in
	sun/tools/ClassDeclaration.java
Message-ID: <20130619210322.583364834A@hg.openjdk.java.net>

Changeset: e1b18a666f76
Author:    khazra
Date:      2013-06-19 14:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b18a666f76

8016698: Cleanup overrides warning in sun/tools/ClassDeclaration.java
Summary: Override Object.hashCode()
Reviewed-by: alanb, chegar

! src/share/classes/sun/tools/java/ClassDeclaration.java



From vicente.romero at oracle.com  Wed Jun 19 21:07:38 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 19 Jun 2013 21:07:38 +0000
Subject: hg: jdk8/tl/langtools: 8016610: javac,
	add new internal symbols to make operator resolution faster
Message-ID: <20130619210741.09B524834B@hg.openjdk.java.net>

Changeset: be10ac0081b2
Author:    vromero
Date:      2013-06-19 22:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be10ac0081b2

8016610: javac, add new internal symbols to make operator resolution faster
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java



From mandy.chung at oracle.com  Wed Jun 19 21:40:24 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Jun 2013 14:40:24 -0700
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C19E91.1050008@oracle.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <1371626905.2715.25.camel@cirrus>
	<1371627245.2715.28.camel@cirrus> <51C19E91.1050008@oracle.com>
Message-ID: <51C22548.1070709@oracle.com>

On 6/19/13 5:05 AM, David Holmes wrote:
> Hi Thomas,
>
> I think I'm going to need a lot more time to understand this issue 
> completely. The synchronization being used seems complex and somewhat 
> ill-defined, and also inadequate. I'm not convinced that adding code 
> inside a synchronized block really fixes a race condition caused by 
> unsynchronized access - but it may well narrow the window significantly.

It'll be good to get your time to look into it.  In fact I suggested 
this fix to Thomas while I do raise a question to myself whether we 
should attempt to clean up the synchronization in this fix (this code 
was implemented before the new Java memory model in 1.5).

Here is my understanding why I think the suggested fix is adequate.

r.queue will be set to ENQUEUED when enqueued and set to NULL when dequeued.

1) Read access to r.queue

    a) no lock to read r.queue
       in Reference.enqueue() method and ReferenceHandler thread

    possibly race is that when calling RQ.enqueue(Reference) method
    (i) it's already enqueued
    (ii) it's already dequeued
    RQ.enqueue(Reference) has to handle that (where the bug is)

    b) Reference.isEnqueued holds the Reference object monitor

    this.next is null initially and is set by the VM to non-null
    pending for enqueue.  I believe checking this.next != null
    is an optimization.

    Potential race is that the reference may be dequeued which
    doesn't hold the Reference object lock.  Is this a bug?

    This race is acceptable in my opinion as I think the isEnqueued
    method is useful to determine when a referent has been GC'ed
    and then followed by dequeuing it from the queue.  If there
    are threads that doing dequeuing, the code calling isEnqueued
    will prepare for the race when isEnqueued returning true,
    the reference may have been dequeued shortly.
    Precisely handling the race that isEnqueued returns true while
    it may be dequeued doesn't prevent this situation.

2) Write to r.queue
    a) acquire Reference object monitor and ReferenceQueue.lock
       to set r.queue to ENQUEUED

       Potential race in RQ.enqueue method
         synchronized (r) {
             if (r.queue == ENQUEUED) return false;
             synchronized (lock) {
                if (r.queue != this) return false;
             ...

       Moving if (r.queue == ENQUEUED) line to after acquiring lock
makes it easier to understand and maintain but I don't see
       a race in the existing code without holding lock.

    b) acquire ReferenceQueue.lock to set r.queue to NULL
       ReferenceQueue.poll and remove methods calling reallyPoll method

       I don't know the history.  The nested lock inversion problem
       is probably the reason why it doesn't acquire the Reference object
       monitor to dequeue.

       This one is related to whether Reference.isEnqueued() should
       return (see above).

Mandy



From mandy.chung at oracle.com  Wed Jun 19 22:49:06 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Jun 2013 15:49:06 -0700
Subject: RFR (XS): 8014890 : Reference queues may return more entries
	than expected
In-Reply-To: <51C17453.60400@gmail.com>
References: <1371589723.2524.43.camel@cirrus> <51C11BB7.9030202@oracle.com>
	<1371626250.2715.19.camel@cirrus> <51C17453.60400@gmail.com>
Message-ID: <51C23562.5060406@oracle.com>

On 6/19/13 2:05 AM, Peter Levart wrote:
>
> It doesn't make a difference between Reference.isEnqueued() and 
> ReferenceQueue.poll(), since there isn't any synchronization between 
> the two. So isEnqueued() can still be returning true while another 
> thread has already de-queued the instance. I guess the real use of 
> isEnqueued() method is reliable detection of false -> true transition 
> only.
>

I think the isEnqueued method is useful to determine when a
referent has been GC'ed. If there are threads that remove them
from the queue, the code calling isEnqueued should prepare for
the race when isEnqueued returning true, the reference may
have been dequeued shortly.  That seems to be acceptable to
return true when another thread has already dequeued it while
not costing much performance tradeoff.

On the other hand, I agree that it'd be nice if we can clean up
the synchronization logic.

> I can't see why the isEnqueued() method checks for both (next != null 
> && queue == ENQUEUED). Wouldn't the check for (queue == ENQUEUED) be 
> enough? In that case the Reference.queue field could be made volatile 
> and synchronization on Reference instance removed.
>

I also thought about that.  The uncertainty I have is any performance 
implication that we need to concern about.   Thomas - can you also find 
out from the GC team?

It looks to me that next != null is an optimization since next == null 
if not pending to be enqueued or not enqueued.

> While you're at it, the reallyPoll() could optimize the double 
> volatile read from head and only perform it once:
>
>     private Reference reallyPoll() {       /* Must hold 
> lock */
>         Reference r = head;
>         if (r != null) {
>             head = (r.next == r) ? null : r.next;
>             r.queue = NULL;
>             r.next = r;
>             queueLength--;
>             if (r instanceof FinalReference) {
>                 sun.misc.VM.addFinalRefCount(-1);
>             }
>             return r;
>         }
>         return null;
>     }
>
>

Good catch.

Mandy


From mike.duigou at oracle.com  Thu Jun 20 00:22:04 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 17:22:04 -0700
Subject: RFR: 8017088 : (s) Map/HashMap.compute() incorrect with key mapping
	to null value 
Message-ID: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>

Hello all;

This is a fix to the Map.compute() default method and HashMap.compute() implementation to correct the handling of keys mapped to null values when the function returns null. This situation should result in the key being removed but it was not.

http://cr.openjdk.java.net/~mduigou/JDK-8017088/0/webrev/

I am strongly considering moving all of the current looping defaults in Map to ConcurrentMap and replacing them with implementations which throw ConcurrentModificationException rather than retrying. The current implementation of Map.compute() default comes close to breaking atomicity by adding the containsKey() check. (It doesn't because the subsequent remove() when oldValue = null can't succeed for any known ConcurrentMap implementations).

Mike

From kurchi.subhra.hazra at oracle.com  Thu Jun 20 00:31:42 2013
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Thu, 20 Jun 2013 00:31:42 +0000
Subject: hg: jdk8/tl/jdk: 7025238: HttpURLConnection does not handle URLs with
	an empty path component.
Message-ID: <20130620003156.209A54834F@hg.openjdk.java.net>

Changeset: 2b156531b7eb
Author:    arieber
Date:      2013-06-19 17:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b156531b7eb

7025238: HttpURLConnection does not handle URLs with an empty path component.
Summary: Prepend a '/' to file when path is empty
Reviewed-by: chegar, khazra

! src/share/classes/sun/net/www/http/HttpClient.java
+ test/sun/net/www/http/HttpClient/B7025238.java



From david.holmes at oracle.com  Thu Jun 20 04:51:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Jun 2013 14:51:30 +1000
Subject: RFR: 8017088 : (s) Map/HashMap.compute() incorrect with key
	mapping to null value
In-Reply-To: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>
References: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>
Message-ID: <51C28A52.8030202@oracle.com>

Hi Mike,

On 20/06/2013 10:22 AM, Mike Duigou wrote:
> Hello all;
>
> This is a fix to the Map.compute() default method and HashMap.compute() implementation to correct the handling of keys mapped to null values when the function returns null. This situation should result in the key being removed but it was not.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8017088/0/webrev/

In Map if we get to line 1030 we retry the loop, but we don't re-read 
the currently mapped value even though the comment indicates it has 
changed. I don't quite grok this.

Also watch for spacing: if(oldValue  -> if (oldValue

> I am strongly considering moving all of the current looping defaults in Map to ConcurrentMap and replacing them with implementations which throw ConcurrentModificationException rather than retrying. The current implementation of Map.compute() default comes close to breaking atomicity by adding the containsKey() check. (It doesn't because the subsequent remove() when oldValue = null can't succeed for any known ConcurrentMap implementations).

I seem to recall this being discussed before but can't find relevant 
emails ...

You would need to revise specs regarding throwing, or not, of CME.

David

> Mike
>


From mike.duigou at oracle.com  Thu Jun 20 05:05:36 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 19 Jun 2013 22:05:36 -0700
Subject: RFR: 8017088 : (s) Map/HashMap.compute() incorrect with key
	mapping to null value
In-Reply-To: <51C28A52.8030202@oracle.com>
References: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>
	<51C28A52.8030202@oracle.com>
Message-ID: <078B95FA-B510-48EE-B3DE-D2D212FB72A9@oracle.com>

Thanks for the feedback.

On Jun 19 2013, at 21:51 , David Holmes wrote:

> Hi Mike,
> 
> On 20/06/2013 10:22 AM, Mike Duigou wrote:
>> Hello all;
>> 
>> This is a fix to the Map.compute() default method and HashMap.compute() implementation to correct the handling of keys mapped to null values when the function returns null. This situation should result in the key being removed but it was not.
>> 
>> http://cr.openjdk.java.net/~mduigou/JDK-8017088/0/webrev/
> 
> In Map if we get to line 1030 we retry the loop, but we don't re-read the currently mapped value even though the comment indicates it has changed. I don't quite grok this.

The putIfAbsent is assigning to oldValue the current value. If it turns out to be null (meaning the value was previously absent) then we return. If it is non-null then our put failed so we loop. We don't have to read it again.

(yeah, I'm not a big fan of assignment in conditionals [hence my frequent use of yoda tests] but the existing default impls use them heavily).

> Also watch for spacing: if(oldValue  -> if (oldValue

Oops, forgot to restyle. 

> 
>> I am strongly considering moving all of the current looping defaults in Map to ConcurrentMap and replacing them with implementations which throw ConcurrentModificationException rather than retrying. The current implementation of Map.compute() default comes close to breaking atomicity by adding the containsKey() check. (It doesn't because the subsequent remove() when oldValue = null can't succeed for any known ConcurrentMap implementations).
> 
> I seem to recall this being discussed before but can't find relevant emails ...

I brought it up to EG as one of the topics in this message:

http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-April/001645.html

Nobody expressed an opinion on the idea and I got distracted and haven't had a chance to follow up.

> You would need to revise specs regarding throwing, or not, of CME.

Yes, understood.

Mike

From victor2 at ukr.net  Thu Jun 20 07:46:04 2013
From: victor2 at ukr.net (Victor Polischuk)
Date: Thu, 20 Jun 2013 10:46:04 +0300
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
Message-ID: <43725.1371714364.8756624963237117952@ffe16.ukr.net>

Hi Brain,

I believe that you can reuse "zeros" array which is declared in the class to improve:

    // Pad with internal zeros if necessary.
    // Don't pad if we're at the beginning of the string.
    if ((s.length() < digits) && (sb.length() > 0))
        for (int i=s.length(); i 0)
        for (int i = digits - s.length(); i > 0; i -= 63)
            sb.append(i > 63 ? zeros[63] : zeros[i]);

Regards,
Victor Polischuk

 --- Original message ---
From: "Brian Burkhalter" 
Date: 19 June 2013, 22:59:03

 
> Continuing on from this thread
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html
> 
> here is a new Request for Review, this time for
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
> 
> The webrev is here
> 
> http://cr.openjdk.java.net/~bpb/4641897/
> 
> The code changes have been reviewed by me and regression tests have been run on my development machine including the updated test which is in the webrev. Performance testing has been performed only insofar as to verify improvement at bit lengths much larger than the algorithm crossover threshold with the understanding that, as for 4837946 and 4646474, the threshold is subject to adjustment pending performance evaluation on a mix of platforms.
> 
> Thanks,
> 
> Brian


From paul.sandoz at oracle.com  Thu Jun 20 08:01:47 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 20 Jun 2013 10:01:47 +0200
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51C1EA92.9010102@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com>
Message-ID: <422CB789-3B08-4032-9F8E-145337AF69B1@oracle.com>


On Jun 19, 2013, at 7:29 PM, Henry Jen  wrote:

> A ping to wake up the thread, there is a minor update regard the use of
> @apiNote since last email.
> 
> Thanks in advance for reviewing.
> 

Looks good.

Paul.


> Cheers,
> Henry
> 
> 
> On 06/15/2013 04:28 PM, Henry Jen wrote:
>> Reflecting feedbacks received so far, please see
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/webrev/
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/specdiff
>> 
>> Cheers,
>> Henry
>> 
>> 
>> On 06/11/2013 02:04 PM, Henry Jen wrote:
>>> Hi,
>>> 
>>> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
>>> 
>>> Highlight of changes,
>>> 
>>> - Comparators class is now only package-private implementations. The
>>> public static methods have been move to other arguably more appropriate
>>> places, mostly in Comparator.
>>> 
>>> - Comparator.reverseOrder() is renamed to Comparator.reversed()
>>> 
>>> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
>>> wrap up a comparator to be null-friendly.
>>> 
>>> To see the API changes, found the specdiff at
>>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
>>> 
>>> Cheers,
>>> Henry
>>> 
>> 
> 



From peter.levart at gmail.com  Thu Jun 20 08:05:49 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 20 Jun 2013 10:05:49 +0200
Subject: RFR: 8017088 : (s) Map/HashMap.compute() incorrect with key
	mapping to null value
In-Reply-To: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>
References: <1D22E585-FC95-43DA-8249-16BBDF99F290@oracle.com>
Message-ID: <51C2B7DD.10208@gmail.com>

On 06/20/2013 02:22 AM, Mike Duigou wrote:
> Hello all;
>
> This is a fix to the Map.compute() default method and HashMap.compute() implementation to correct the handling of keys mapped to null values when the function returns null. This situation should result in the key being removed but it was not.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8017088/0/webrev/
>
> I am strongly considering moving all of the current looping defaults in Map to ConcurrentMap and replacing them with implementations which throw ConcurrentModificationException rather than retrying. The current implementation of Map.compute() default comes close to breaking atomicity by adding the containsKey() check. (It doesn't because the subsequent remove() when oldValue = null can't succeed for any known ConcurrentMap implementations).

...and it is fortunate that ConcurrentMap.remove(key, null) just returns 
false and doesn't throw NPE.

Yes, that would be a good idea. Non-ConcurrentMaps can't guarantee 
deterministic behaviour when modified from multiple threads and there's 
always some danger that their internal state is corrupted in such a way 
to cause infinite looping. It's better to fail that to loop in such cases.

Regards, Peter

>
> Mike



From vicente.romero at oracle.com  Thu Jun 20 07:46:11 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 20 Jun 2013 07:46:11 +0000
Subject: hg: jdk8/tl/langtools: 8016613: javac should avoid source 8 only
	analysis when compiling for source 7
Message-ID: <20130620074617.BFF2F48359@hg.openjdk.java.net>

Changeset: 6debfa63a4a1
Author:    vromero
Date:      2013-06-20 08:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6debfa63a4a1

8016613: javac should avoid source 8 only analysis when compiling for source 7
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java



From paul.sandoz at oracle.com  Thu Jun 20 08:52:26 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 20 Jun 2013 08:52:26 +0000
Subject: hg: jdk8/tl/jdk: 8016308: Updates to j.u.stream.Node/Nodes
Message-ID: <20130620085254.ED7AD4835E@hg.openjdk.java.net>

Changeset: 656ea2349aa5
Author:    psandoz
Date:      2013-06-20 10:45 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/656ea2349aa5

8016308: Updates to j.u.stream.Node/Nodes
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SliceOps.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java



From paul.sandoz at oracle.com  Thu Jun 20 09:04:05 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 20 Jun 2013 09:04:05 +0000
Subject: hg: jdk8/tl/jdk: 8016324: filter/flatMap pipeline sinks should pass
	size information to downstream sink
Message-ID: <20130620090425.63D424835F@hg.openjdk.java.net>

Changeset: 85524d9839dc
Author:    psandoz
Date:      2013-06-20 11:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85524d9839dc

8016324: filter/flatMap pipeline sinks should pass size information to downstream sink
Reviewed-by: chegar, mduigou
Contributed-by: Brian Goetz 

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java



From paul.sandoz at oracle.com  Thu Jun 20 09:16:49 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 20 Jun 2013 09:16:49 +0000
Subject: hg: jdk8/tl/jdk: 8016455: Sync stream tests from lambda to tl
Message-ID: <20130620091743.0DF7F48362@hg.openjdk.java.net>

Changeset: f758d7c24396
Author:    psandoz
Date:      2013-06-20 11:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f758d7c24396

8016455: Sync stream tests from lambda to tl
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 

! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/NodeTest.java
! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java



From scolebourne at joda.org  Thu Jun 20 09:44:19 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 20 Jun 2013 10:44:19 +0100
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
In-Reply-To: 
References: 
Message-ID: 

Like others, I would prefer isNotNull() to notNull(). Mainly for
consistency, but also for dicoverability is IDE autocomplete (as the
methods would then be next to one another)
Stephen


On 30 April 2013 23:45, Mike Duigou  wrote:
> Hello all;
>
> Another changeset coming from the lambda libraries effort. This one is two small additions to the Objects class. The introduced methods are not really intended to be used directly, comparison operators work better in imperative logic, but the methods will be very useful as Predicates.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8013712/0/webrev/
>
> Thanks,
>
> Mike


From daniel.fuchs at oracle.com  Thu Jun 20 09:49:12 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 20 Jun 2013 11:49:12 +0200
Subject: RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info()
	doesn't log without configuration
In-Reply-To: <51C1CEE9.9010200@oracle.com>
References: <51C1CEE9.9010200@oracle.com>
Message-ID: <51C2D018.3090403@oracle.com>

Hi,

Here is a second revision.



I have added a TestGetGlobalConcurrent.java test which is
somewhat similar to the other TestGetGlobal and TestGetGlobal2
tests - excepts that it creates multiple concurrent threads
which will race to initialize the LogManager in different
manners.

-- daniel

On 6/19/13 5:31 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a proposed fix for:
>
> 7184195 - java.util.logging.Logger.getGlobal().info()
>            doesn't log without configuration
>
> Jim who was the original evaluator of this bug find out
> that the root cause of the issue was that LogManager hadn't been
> initialized yet, and therefore the global Logger returned had its
> manager instance 'null' - and more to the point - had no configuration
> since the configuration is established by the LogManager.
>
> The fix proposed is simple. In getGlobal() we check whether
> the 'manager' variable is null - and if it is, we initialize it
> by calling LogManager.getLogManager().
> This is a pattern which is already present at other places in
> the Logger.java class file.
>
> 
>
> However - initialization of LogManager has proved to be fragile
> in the past - in particular wrt deadlocks between Logger and
> LogManager caused by circular class initialization.
>
> Therefore, I have added two test files TestGetGlobal.java and
> TestGetGlobal2.java which try to trigger such deadlocks by
> calling Logger.getGlobal()
> or Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) before the
> LogManager class is initialized.
>
> The tests have a bunch of @run line trying to do so with
> different configurations, including by using custom LogManager
> subclasses, with and without a security manager on.
>
> I have seen no issue so far.
>
> best regards,
>
> -- daniel



From paul.sandoz at oracle.com  Thu Jun 20 09:35:01 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Thu, 20 Jun 2013 09:35:01 +0000
Subject: hg: jdk8/tl/jdk: 8016139: PrimitiveIterator.forEachRemaining
Message-ID: <20130620093516.D776548363@hg.openjdk.java.net>

Changeset: 562f5cf13a9c
Author:    psandoz
Date:      2013-06-20 11:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/562f5cf13a9c

8016139: PrimitiveIterator.forEachRemaining
Reviewed-by: alanb

! src/share/classes/java/util/PrimitiveIterator.java



From daniel.fuchs at oracle.com  Thu Jun 20 10:50:22 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 20 Jun 2013 12:50:22 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51C1F788.7090707@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
	<51C1733A.7020008@oracle.com> <51C1F788.7090707@oracle.com>
Message-ID: <51C2DE6E.3030605@oracle.com>

On 6/19/13 8:25 PM, Mandy Chung wrote:
> On 6/19/13 2:00 AM, Daniel Fuchs wrote:
>> On 6/13/13 10:05 PM, Mandy Chung wrote:
>>> Daniel,
>>>
>>> I wonder what the list of logger names (loggers1 and loggers2) returned
>>> by LoggingMXBean contains and that may include loggers in the running VM
>>> other than the ones created and kept a strong reference by the test. In
>>> other words,  would it be possible for the running VM that has loggers
>>> that are not created by the test and got GC'ed?
>>
>> Hi Mandy,
>>
>> I have added a System.out.println to print the list of logger names.
>> By running jtreg on my machine I could see that this list does contain
>> system logger names (mostly JMX loggers).
>> I believe those loggers are strongly referenced by JMX.
>> Other than those I could see "" and "global".
>>
>> 
>>
>> However - since this seems to be an intermittent failure - maybe the
>> logger that was causing the problem had already been gc'ed before
>> getLoggerNames() and therefore didn't appear in this list.
>> The test would fail when that 'transient' logger appears in the
>> list but is gc'ed before getLoggerLevel() is called.
>>
>> Anyway - it's possible that some platform class
>> is calling:
>>    Logger log = Logger.getLogger();
>>    if (log.isLoggable()) {...}
>> without keeping a strong reference to the logger in the class.
>>
>> In that case I guess it would be possible for that 
>> to appear transiently in the logger's name list - and be gc'ed
>> just after...
>>
>
> Is this test running in othervm mode?  or samevm mode?   I would think
> there is no logger created when checkAttributes is being called.

Hi Mandy,

AFAICT this test is running in samevm mode.

> The checkAttributes method is intended to verify LoggingMXBean and
> PlatformLoggingMXBean are functionally equivalent.  I would suggest to
> just check the two loggers created by this test and simply skip others
> at the beginning of the loop to make the test reliable. What you have is
> okay to print out warning but I think it's not necessary in the fix.  In
> addition, the check on mxbean1.getParentLoggerName !=
> mxbean2.getParentLoggerName may also run into this race when a logger
> being gc'ed.

Right. I have changed the test to temporarily retrieve the named loggers
and keep them in an HashMap - this way they should not be gc'ed.



-- daniel


>
> Mandy
>



From daniel.fuchs at oracle.com  Thu Jun 20 10:52:14 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 20 Jun 2013 12:52:14 +0200
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51C2DE6E.3030605@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
	<51C1733A.7020008@oracle.com> <51C1F788.7090707@oracle.com>
	<51C2DE6E.3030605@oracle.com>
Message-ID: <51C2DEDE.5000509@oracle.com>

On 6/20/13 12:50 PM, Daniel Fuchs wrote:
 > Right. I have changed the test to temporarily retrieve the named loggers
 > and keep them in an HashMap - this way they should not be gc'ed.

Wrong URL, sorry:



-- daniel


From forax at univ-mlv.fr  Thu Jun 20 13:10:41 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 20 Jun 2013 15:10:41 +0200
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
In-Reply-To: 
References: 
	
Message-ID: <51C2FF51.3060802@univ-mlv.fr>

Yes, a fine idea.

R?mi

On 06/20/2013 11:44 AM, Stephen Colebourne wrote:
> Like others, I would prefer isNotNull() to notNull(). Mainly for
> consistency, but also for dicoverability is IDE autocomplete (as the
> methods would then be next to one another)
> Stephen
>
>
> On 30 April 2013 23:45, Mike Duigou  wrote:
>> Hello all;
>>
>> Another changeset coming from the lambda libraries effort. This one is two small additions to the Objects class. The introduced methods are not really intended to be used directly, comparison operators work better in imperative logic, but the methods will be very useful as Predicates.
>>
>> http://cr.openjdk.java.net/~mduigou/JDK-8013712/0/webrev/
>>
>> Thanks,
>>
>> Mike



From xuelei.fan at oracle.com  Thu Jun 20 14:49:48 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 20 Jun 2013 14:49:48 +0000
Subject: hg: jdk8/tl/jdk: 8017157: catch more exception in test
	RejectClientRenego
Message-ID: <20130620145013.A936B4836D@hg.openjdk.java.net>

Changeset: a44bd993ce93
Author:    xuelei
Date:      2013-06-20 07:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a44bd993ce93

8017157: catch more exception in test RejectClientRenego
Reviewed-by: vinnie

! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java



From david.r.chase at oracle.com  Thu Jun 20 15:04:01 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 20 Jun 2013 11:04:01 -0400
Subject: RFR : 7129185 : (L) Add
	Collections.{checked|empty|unmodifiable}Navigable{Map|Set}
In-Reply-To: 
References: 
	<993D9F3C-DA62-47B0-8FB2-A5DE14952580@oracle.com>
	
	<0608A8B1-A399-4E85-BBFD-AAFE306FE949@oracle.com>
	<277951B8-6645-4111-8DE3-5EDCFF8A20E8@oracle.com>
	
	
Message-ID: 

I'm not a reviewer, but I am happy to see that you always print the random seed, and not just in the case of graceful test failure -- because otherwise if the VM crashes, too bad for the poor fool who has to try to reproduce that.

David

On 2013-06-18, at 8:59 PM, Mike Duigou  wrote:

> I have now updated MOAT to test the Collections wrappers. I hope that adding additional classes doesn't take the already long runtime of this class over the timeout threshold.
> 
> The revised webrev, which includes only changes to tests, is here:
> 
> http://cr.openjdk.java.net/~mduigou/JDK-7129185/6/webrev/
> 
> The very pleasing news is that nothing failed! 
> 
> Mike
> 
> On Jun 18 2013, at 15:34 , Martin Buchholz wrote:
> 
>> 
>> Looking at MOAT.java, I'm a little surprised that I didn't systematically test the implementations in Collections.java, even though e.g. it has a section for empty collections.  How hard would it be to add such support?
> 



From david.r.chase at oracle.com  Thu Jun 20 15:14:25 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 20 Jun 2013 11:14:25 -0400
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
	
	
Message-ID: 

Not a reviewer, but depressingly much experience hacking Java FP.

It all looks right to me (i.e., exponent extraction and rounding modes including the round-up carry to the next higher power of two) and I like the comments explaining the little hacks, and I trust the testing to smoke out fencepost errors.

David

On 2013-06-18, at 8:45 PM, Brian Burkhalter  wrote:

> The updated comments have been propagated to the online webrev
> 
> http://cr.openjdk.java.net/~bpb/7131192/
> 
> On Jun 17, 2013, at 11:39 AM, Brian Burkhalter wrote:
> 
>> I'll update this but without reposting the webrev until I can upload the HTML version.
>> 
>> On Jun 17, 2013, at 11:37 AM, Louis Wasserman wrote:
>> 
>>> You're right, it'd be WIDTH - 1, but since most of the comments refer to BITS + 1, that evens out nicely.
>>> 
>>> On Mon, Jun 17, 2013 at 11:34 AM, Brian Burkhalter wrote:
>>> Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied" bit?
>>> 
>>> On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:
>>> 
>>>> The comments mention SIGNIFICAND_BITS, which I think should probably be SIGNIFICAND_WIDTH?
>> 
> 



From mike.duigou at oracle.com  Thu Jun 20 16:18:28 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 20 Jun 2013 16:18:28 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130620161903.7947148370@hg.openjdk.java.net>

Changeset: 49b78ec058fb
Author:    mduigou
Date:      2013-06-20 07:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49b78ec058fb

8017088: Map/HashMap.compute() incorrect with key mapping to null value
Reviewed-by: dl, dholmes, plevart

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Map.java
! test/java/util/Map/Defaults.java

Changeset: 9fa37bd38d4b
Author:    mduigou
Date:      2013-06-20 08:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fa37bd38d4b

Merge




From ivan.gerasimov at oracle.com  Thu Jun 20 16:50:27 2013
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 20 Jun 2013 20:50:27 +0400
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51C1EA92.9010102@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com>
Message-ID: <51C332D3.7090702@oracle.com>

>Returns a comparator compares {@link Comparable} type in natural order.

Shouldn't be "Returns a comparator that compares"?

Sincerely,
Ivan

On 19.06.2013 21:29, Henry Jen wrote:
> A ping to wake up the thread, there is a minor update regard the use of
> @apiNote since last email.
>
> Thanks in advance for reviewing.
>
> Cheers,
> Henry
>
>
> On 06/15/2013 04:28 PM, Henry Jen wrote:
>> Reflecting feedbacks received so far, please see
>>
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/webrev/
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/specdiff
>>
>> Cheers,
>> Henry
>>
>>
>> On 06/11/2013 02:04 PM, Henry Jen wrote:
>>> Hi,
>>>
>>> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
>>>
>>> Highlight of changes,
>>>
>>> - Comparators class is now only package-private implementations. The
>>> public static methods have been move to other arguably more appropriate
>>> places, mostly in Comparator.
>>>
>>> - Comparator.reverseOrder() is renamed to Comparator.reversed()
>>>
>>> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
>>> wrap up a comparator to be null-friendly.
>>>
>>> To see the API changes, found the specdiff at
>>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
>>>
>>> Cheers,
>>> Henry
>>>
>
>



From chris.hegarty at oracle.com  Thu Jun 20 17:55:59 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 20 Jun 2013 17:55:59 +0000
Subject: hg: jdk8/tl/jdk: 8014499: MulticastSocket should enable
	IP_MULTICAST_ALL (lnx)
Message-ID: <20130620175626.7AADB48379@hg.openjdk.java.net>

Changeset: bf2bacf934d1
Author:    chegar
Date:      2013-06-20 18:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf2bacf934d1

8014499: MulticastSocket should enable IP_MULTICAST_ALL (lnx)
Reviewed-by: alanb, chegar
Contributed-by: John Zavgren , Chris Hegarty 

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
+ test/java/net/MulticastSocket/Promiscuous.java



From xueming.shen at oracle.com  Thu Jun 20 18:48:13 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 20 Jun 2013 11:48:13 -0700
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
Message-ID: <51C34E6D.4000502@oracle.com>

Hi,

The zip time related changes[1] I pushed back last month appears
to have the compatibility risk of breaking existing code. The main
idea in that changeset is to use the more accurate and timezone
insensitive utc time stored in the extra field for the ZipEntry.set/getTime()
if possible. However it turns out the reality is that the code out there
might have already had some interesting workaround/hack solution
to workaround the problem that the time stamp stored in the "standard'
zip entry header is a MS-DOS standard date/time, which is a "local
date/time" and sensitive to timezone, in which, if the zip is archived
in time zone A (our implementation converts the "java" time to dos
time by using the default tz A) and then transferred/un-archived in
a different zone B (use default tz B to convert back to java time), we
have a time stamp mess up. The "workaround" from pack200 for this
issue when pack/unpacking a jar file is to "specify/recommend/suggest"
in its spec that the "time zone" in a jar file entry is assumed to be "UTC",
so the pack/unpack200 implementation set the "default time" to utc
before the pack/unpack and set it back to the original after that. It worked
"perfectly" for a roundtrip pack/unpacking, until the changeset [2], in
which ZipEntry.getTime() (packing) returns a real utc time and the following
ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time
entry, this is the root cause of this regression.

Given the facts that
(1) there are actually two real physical time stamps in a zip file header,
one is in the date/time fields, which is MS-DOS-local-date/time-with-2-
seconds-granularity , one is in the extra data field, which is UTC-1-second
-granularity
(2) and there are applications over there that have dependency on the
MS-DOS date/time stamp.

I'm proposing the following approach to add the functionality of supporting
the "utc-date/time-with-1-second granularity" and keep the old behavior
of the get/setTime() of the ZipEntry.

(1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
      To set via the old setTime() will only store the time into zip's standard
      date/time field, which is in MS-DOS date/time. And getTime() only returns
      the date/time from that field, when read from the zip file/stream.
(2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
      and the last modified time set via the new method will also set the "time",
      and the getLastModifiedTime() also returns the "time", if the UTC time
      stamp fields are not set in the zip file header. The idea is that for the new
      application, the recommendation is to use ZipEntry.set/getLastModifiedTime()
      for better/correct time stamp, but the existing apps keep the same behavior.
(3) jar and ZipOutputStream are updated to use the set/getLastModifiedTime().
(4) Pack/unpack continues to use the set/getTime(), so the current workaround
      continues work. I will leave this to Kuma to decide how it should be handled
      going forward. (there are two facts need to be considered here, a) the
      existing jar file might not have the utc time instored, and b) all "extra" data
      are wiped out during the pack/unpacking process)
(5) additionally add another pair of atime/get/setLastAccessTime and
      ctime/get/setCreationTime().
(6) The newly added 3 pairs of the m/a/ctime get/set methods use the "new"
      nio FileTime, instead of the "long". This may add some additional cost of
      conversion when working with them, but may also help improve the
      performance if the time stamps are directly from nio  file system when
      get/set XYZTime. Good/bad?

http://cr.openjdk.java.net/~sherman/8015666/webrev/

Comment, option and suggestion are appreciated.

-Sherman

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f


From martinrb at google.com  Thu Jun 20 20:53:11 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 20 Jun 2013 13:53:11 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
	
	
	
Message-ID: 

I am an openjdk Reviewer, and this change Looks Good To Me.

Thanks Louis, David, Brian.

Again I suggest we make it easier to give out reviewer bits.  For example,
David may not have been making many direct contributions to openjdk, but he
certainly has related expertise and a track record.

Martin



On Thu, Jun 20, 2013 at 8:14 AM, David Chase wrote:

> Not a reviewer, but depressingly much experience hacking Java FP.
>
> It all looks right to me (i.e., exponent extraction and rounding modes
> including the round-up carry to the next higher power of two) and I like
> the comments explaining the little hacks, and I trust the testing to smoke
> out fencepost errors.
>
> David
>
> On 2013-06-18, at 8:45 PM, Brian Burkhalter 
> wrote:
>
> > The updated comments have been propagated to the online webrev
> >
> > http://cr.openjdk.java.net/~bpb/7131192/
> >
> > On Jun 17, 2013, at 11:39 AM, Brian Burkhalter wrote:
> >
> >> I'll update this but without reposting the webrev until I can upload
> the HTML version.
> >>
> >> On Jun 17, 2013, at 11:37 AM, Louis Wasserman wrote:
> >>
> >>> You're right, it'd be WIDTH - 1, but since most of the comments refer
> to BITS + 1, that evens out nicely.
> >>>
> >>> On Mon, Jun 17, 2013 at 11:34 AM, Brian Burkhalter<
> brian.burkhalter at oracle.com> wrote:
> >>> Would it be WIDTH or WIDTH - 1, i.e., with or without the "implied"
> bit?
> >>>
> >>> On Jun 17, 2013, at 11:32 AM, Louis Wasserman wrote:
> >>>
> >>>> The comments mention SIGNIFICAND_BITS, which I think should probably
> be SIGNIFICAND_WIDTH?
> >>
> >
>
>


From brian.burkhalter at oracle.com  Thu Jun 20 21:26:09 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 20 Jun 2013 14:26:09 -0700
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
	
	
	
	
Message-ID: 

Hi Martin,

On Jun 20, 2013, at 1:53 PM, Martin Buchholz wrote:

> I am an openjdk Reviewer, and this change Looks Good To Me.

Thanks For Your Review. ;-)

Unfortunately this cannot be integrated before

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017958.html

or its regression test will fail.

> Thanks Louis, David, Brian.

Indeed!

> Again I suggest we make it easier to give out reviewer bits.  For example, David may not have been making many direct contributions to openjdk, but he certainly has related expertise and a track record.

I'll leave detailed comment on this to others, but I agree in principle.

Thanks,

Brian

From henry.jen at oracle.com  Thu Jun 20 22:36:00 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 20 Jun 2013 15:36:00 -0700
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51C332D3.7090702@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com> <51C332D3.7090702@oracle.com>
Message-ID: <51C383D0.7080006@oracle.com>

On 06/20/2013 09:50 AM, Ivan Gerasimov wrote:
>>Returns a comparator compares {@link Comparable} type in natural order.
> 
> Shouldn't be "Returns a comparator that compares"?
>

Fixed, I updated the webrev with this and a minor update for NullComparator.

The difference from previous webrev is in following changeset,

http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0ca783c9c628

Cheers,
Henry



From michael.hixson at gmail.com  Thu Jun 20 22:45:10 2013
From: michael.hixson at gmail.com (Michael Hixson)
Date: Thu, 20 Jun 2013 15:45:10 -0700
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51C383D0.7080006@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com> <51C332D3.7090702@oracle.com>
	<51C383D0.7080006@oracle.com>
Message-ID: 

+ return new NullComparator(nullFirst, real == null ? null :
real.thenComparing(other));

Should that be "other" instead of the second "null", like this?

+ return new NullComparator(nullFirst, real == null ? other :
real.thenComparing(other));

Also, if Comparator.nullsFirst(null) and nullsLast(null) no longer
throw, I think it's worth mentioning what their behavior is in the
javadocs.  My suggestion:

"If the specified comparator is {@code null}, then the returned
comparator considers all non-null values to be equal."

-Michael

On Thu, Jun 20, 2013 at 3:36 PM, Henry Jen  wrote:
> On 06/20/2013 09:50 AM, Ivan Gerasimov wrote:
>>>Returns a comparator compares {@link Comparable} type in natural order.
>>
>> Shouldn't be "Returns a comparator that compares"?
>>
>
> Fixed, I updated the webrev with this and a minor update for NullComparator.
>
> The difference from previous webrev is in following changeset,
>
> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0ca783c9c628
>
> Cheers,
> Henry
>


From eric.mccorkle at oracle.com  Thu Jun 20 23:02:24 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 20 Jun 2013 23:02:24 +0000
Subject: hg: jdk8/tl/langtools: 8007546: ClassCastException on JSR308 tests;
	...
Message-ID: <20130620230228.F40F348392@hg.openjdk.java.net>

Changeset: e9ebff1840e5
Author:    emc
Date:      2013-06-20 19:01 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e9ebff1840e5

8007546: ClassCastException on JSR308 tests
8015993: jck-compiler tests are failed with java.lang.ClassCastException
Summary: Fix ClassCastExceptions arising from addition of AnnotatedType.
Reviewed-by: jjg, abuckley

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java



From martinrb at google.com  Thu Jun 20 23:24:10 2013
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 20 Jun 2013 16:24:10 -0700
Subject: RFR 7192954+4396272: Fix Float.parseFloat to round correctly and
	preserve monotonicity
In-Reply-To: <207D3115-6C73-45CA-A597-7EC483542730@oracle.com>
References: 
	<207D3115-6C73-45CA-A597-7EC483542730@oracle.com>
Message-ID: 

This change Looks Good To Me.

It would be good in future to cc the contributors.

Just to show that I'm paying attention, add an extra asterisk below
to make this a proper javadoc comment (not that it matters much).

1048         /*
1049          * Takes a FloatingDecimal, which we presumably just scanned
in,
1050          * and finds out what its value is, as a double.
1051          *
1052          * AS A SIDE EFFECT, SET roundDir TO INDICATE PREFERRED
1053          * ROUNDING DIRECTION in case the result is really destined
1054          * for a single-precision float.
1055          */
1056         @Override
1057         public double doubleValue() {



On Wed, Jun 12, 2013 at 12:56 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> The original patch has been updated such that it also fixes
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7039391 - Use Math.ulp
> in FloatingDecimal.
>
> The updated patch is at
>
> http://cr.openjdk.java.net/~bpb/7192954_4396272_7039391/
>
> For purposes of comparison, the original patch is left online at the
> location indicated below.
>
> The specific changes in the update are
>
> 1) Use IEEE-754 primitive long instead of primitive double for the
> candidate double, thereby removing FloatingDecimal.ulp() without using any
> Math.* methods.
>
> 2) Remove strictfp from declarations of doubleValue() and floatValue().
>
> 3) In floatValue(), find approximation directly instead of invoking
> doubleValue().
>
> I have code-reviewed the update and ensured that it passes the JTREG tests
> in
>
> * sun/misc/FloatingDecimal
> * java/lang/Double
> * java/lang/Float
> * java/math
>
> If there are other pertinent validations which should be performed please
> point them out.
>
> Once this patch has been officially reviewed I will post the webrev for
> http://bugs.sun.com/view_bug.do?bug_id=7131192 - BigInteger.doubleValue()
> is "depressingly" slow.
>
> Thanks,
>
> Brian
>
> On Jun 11, 2013, at 3:47 PM, Brian Burkhalter wrote:
>
> > This contributed patch
> >
> > http://cr.openjdk.java.net/~bpb/4396272%2b7192954/
> >
> > fixes these two issues:
> >
> > 1) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192954 - Fix
> Float.parseFloat to round correctly and preserve monotonicity
> >
> > 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4396272 - Parsing
> double fails to follow IEEE for largest decimal the should yield 0
> >
> > For 7192954, "stickyRound()" is replaced by actual code development
> containing a correction loop in floatValue() analogous to that in
> doubleValue().
> >
> > For 4396272, when the difference between the scaled big-int versions of
> the exact value and the candidate double value is exactly 1/2*ULP, and the
> candidate value <= 2*Double.MIN_NORMAL, then form the correction statement
> in a way that avoids rounding the intermediate result to zero thereby
> preventing correction.
> >
> > For reference see also this thread:
> >
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014788.html
> >
> > Thanks,
> >
> > Brian
>
>


From henry.jen at oracle.com  Thu Jun 20 23:40:32 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 20 Jun 2013 16:40:32 -0700
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: 
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com> <51C332D3.7090702@oracle.com>
	<51C383D0.7080006@oracle.com>
	
Message-ID: <51C392F0.8070507@oracle.com>

On 06/20/2013 03:45 PM, Michael Hixson wrote:
> + return new NullComparator(nullFirst, real == null ? null :
> real.thenComparing(other));
> 
> Should that be "other" instead of the second "null", like this?
> 
> + return new NullComparator(nullFirst, real == null ? other :
> real.thenComparing(other));
> 
> Also, if Comparator.nullsFirst(null) and nullsLast(null) no longer
> throw, I think it's worth mentioning what their behavior is in the
> javadocs.  My suggestion:
> 
> "If the specified comparator is {@code null}, then the returned
> comparator considers all non-null values to be equal."
> 

You are right on both, both fixed and added extra test.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/197698000f78

webrev updated.

Cheers,
Henry



From brian.burkhalter at oracle.com  Fri Jun 21 00:24:43 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 20 Jun 2013 17:24:43 -0700
Subject: RFR 7192954+4396272: Fix Float.parseFloat to round correctly and
	preserve monotonicity
In-Reply-To: 
References: 
	<207D3115-6C73-45CA-A597-7EC483542730@oracle.com>
	
Message-ID: <731CA7A5-A69C-415A-9032-FEB238A8DC74@oracle.com>

Hi Martin,

On Jun 20, 2013, at 4:24 PM, Martin Buchholz wrote:

> This change Looks Good To Me.

Cool - thanks!

> It would be good in future to cc the contributors.

Good point. It probably is best not to assume that everyone is on core-libs-dev.

> Just to show that I'm paying attention, add an extra asterisk below
> to make this a proper javadoc comment (not that it matters much).
> 
> 1048         /*
> 1049          * Takes a FloatingDecimal, which we presumably just scanned in,
> 1050          * and finds out what its value is, as a double.
> 1051          *
> 1052          * AS A SIDE EFFECT, SET roundDir TO INDICATE PREFERRED
> 1053          * ROUNDING DIRECTION in case the result is really destined
> 1054          * for a single-precision float.
> 1055          */
> 1056         @Override
> 1057         public double doubleValue() {

I'll make this change and update the webrev tomorrow.

Thanks,

Brian

From david.r.chase at oracle.com  Fri Jun 21 01:08:07 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 20 Jun 2013 21:08:07 -0400
Subject: RFR 7131192: BigInteger.doubleValue() is depressingly slow
In-Reply-To: 
References: 
	
	<05033D43-AEAF-4F37-B2F4-F712E1C47DEF@oracle.com>
	
	
	
	
	
Message-ID: <468425FC-1F1A-46BF-8063-25491AD1C3E8@oracle.com>


On 2013-06-20, at 4:53 PM, Martin Buchholz  wrote:

> I am an openjdk Reviewer, and this change Looks Good To Me.
> 
> Thanks Louis, David, Brian.
> 
> Again I suggest we make it easier to give out reviewer bits.  For example, David may not have been making many direct contributions to openjdk, but he certainly has related expertise and a track record.

Thanks for the vote of confidence, and I somewhat agree, but I think it's a tricky call to make.  I have a long track record with compilers, too, but knowing your way around a particular incredibly complex compiler (actually, pair of compilers and an interpreter) doesn't come automatically just because you spent decades with your nose up the wrong end of several other differently complex compilers.

Specialized domain knowledge (FP, sync-free data structures, finite field arithmetic, parallelizing recurrences) is different -- it's a pain to learn, but once you learn it, it applies in many places.

David



From alan.bateman at oracle.com  Fri Jun 21 05:44:04 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 21 Jun 2013 05:44:04 +0000
Subject: hg: jdk8/tl/jdk: 8014377: (dc) DatagramChannel should set
	IP_MULTICAST_ALL=0 (lnx)
Message-ID: <20130621054428.B590E483C3@hg.openjdk.java.net>

Changeset: cd06fc069152
Author:    alanb
Date:      2013-06-20 19:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd06fc069152

8014377: (dc) DatagramChannel should set IP_MULTICAST_ALL=0 (lnx)
Reviewed-by: chegar, jzavgren

! src/solaris/native/sun/nio/ch/Net.c
+ test/java/nio/channels/DatagramChannel/Promiscuous.java



From Alan.Bateman at oracle.com  Fri Jun 21 09:49:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Jun 2013 10:49:22 +0100
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
Message-ID: <51C421A2.3080903@oracle.com>

On 19/06/2013 20:58, Brian Burkhalter wrote:
> Continuing on from this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html
>
> here is a new Request for Review, this time for
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
>
> The webrev is here
>
> http://cr.openjdk.java.net/~bpb/4641897/
>
> The code changes have been reviewed by me and regression tests have been run on my development machine including the updated test which is in the webrev. Performance testing has been performed only insofar as to verify improvement at bit lengths much larger than the algorithm crossover threshold with the understanding that, as for 4837946 and 4646474, the threshold is subject to adjustment pending performance evaluation on a mix of platforms.
>
> Thanks,
>
> Brian
One part that might need attention is getRadixConversionCache as I could 
imagine cases where the synchronization could lead to contention. Have 
you (or Alan) considered alternatives that would limit the 
synchronization to only when the powers cache needs to be expanded?

-Alan.



From weijun.wang at oracle.com  Fri Jun 21 12:29:28 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 21 Jun 2013 12:29:28 +0000
Subject: hg: jdk8/tl/jdk: 8001326: Improve Kerberos caching
Message-ID: <20130621122954.DF90F483D2@hg.openjdk.java.net>

Changeset: 4503e04141f7
Author:    weijun
Date:      2013-06-21 18:26 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4503e04141f7

8001326: Improve Kerberos caching
Reviewed-by: valeriep

! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java
! src/share/classes/sun/security/krb5/EncryptionKey.java
! src/share/classes/sun/security/krb5/KrbApRep.java
! src/share/classes/sun/security/krb5/KrbApReq.java
+ src/share/classes/sun/security/krb5/internal/ReplayCache.java
+ src/share/classes/sun/security/krb5/internal/rcache/AuthList.java
! src/share/classes/sun/security/krb5/internal/rcache/AuthTime.java
+ src/share/classes/sun/security/krb5/internal/rcache/AuthTimeWithHash.java
- src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
+ src/share/classes/sun/security/krb5/internal/rcache/DflCache.java
+ src/share/classes/sun/security/krb5/internal/rcache/MemoryCache.java
- src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
+ test/java/security/testlibrary/Proc.java
! test/sun/security/krb5/auto/AcceptorSubKey.java
+ test/sun/security/krb5/auto/BasicProc.java
! test/sun/security/krb5/auto/Context.java
! test/sun/security/krb5/auto/KDC.java
+ test/sun/security/krb5/auto/NoneReplayCacheTest.java
- test/sun/security/krb5/auto/ReplayCache.java
+ test/sun/security/krb5/auto/ReplayCacheExpunge.java
+ test/sun/security/krb5/auto/ReplayCachePrecise.java
+ test/sun/security/krb5/auto/ReplayCacheTest.java
+ test/sun/security/krb5/auto/ReplayCacheTestProc.java
! test/sun/security/krb5/ccache/EmptyCC.java



From sundararajan.athijegannathan at oracle.com  Fri Jun 21 13:15:41 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 21 Jun 2013 13:15:41 +0000
Subject: hg: jdk8/tl/nashorn: 7 new changesets
Message-ID: <20130621131548.81A9C483D5@hg.openjdk.java.net>

Changeset: 6a75a505301f
Author:    sundar
Date:      2013-06-18 18:43 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6a75a505301f

8012698: [nashorn] tests fail to run with agentvm or samevm
Reviewed-by: hannesw, jlaskey

! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java
! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java
! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java

Changeset: 7276d66b7118
Author:    jlaskey
Date:      2013-06-19 09:10 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7276d66b7118

8010697: DeletedArrayFilter seems to leak memory
Reviewed-by: hannesw, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java
! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java
! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
+ test/script/basic/JDK-8010697.js
+ test/script/basic/JDK-8010697.js.EXPECTED

Changeset: c7c9222cfe69
Author:    sundar
Date:      2013-06-19 21:07 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c7c9222cfe69

8015347: Parsing issue with decodeURIComponent
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/runtime/URIUtils.java
+ test/script/basic/JDK-8015347.js

Changeset: ac404bf3f8c8
Author:    sundar
Date:      2013-06-20 13:45 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ac404bf3f8c8

8017046: Cannot assign undefined to a function argument if the function uses arguments object
Reviewed-by: hannesw

! src/jdk/nashorn/internal/objects/NativeArguments.java
+ test/script/basic/JDK-8017046.js

Changeset: c7672e621b14
Author:    sundar
Date:      2013-06-20 17:34 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c7672e621b14

Merge


Changeset: 8e03121cc286
Author:    sundar
Date:      2013-06-21 16:55 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8e03121cc286

8017260: adjust lookup code in objects.* classes
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/PrototypeObject.java

Changeset: b4e2bccf9598
Author:    sundar
Date:      2013-06-21 17:33 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b4e2bccf9598

Merge




From Alan.Bateman at oracle.com  Fri Jun 21 13:33:08 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 21 Jun 2013 14:33:08 +0100
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
In-Reply-To: <51C34E6D.4000502@oracle.com>
References: <51C34E6D.4000502@oracle.com>
Message-ID: <51C45614.4010205@oracle.com>

On 20/06/2013 19:48, Xueming Shen wrote:
> :
>
> I'm proposing the following approach to add the functionality of 
> supporting
> the "utc-date/time-with-1-second granularity" and keep the old behavior
> of the get/setTime() of the ZipEntry.
>
> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
>      To set via the old setTime() will only store the time into zip's 
> standard
>      date/time field, which is in MS-DOS date/time. And getTime() only 
> returns
>      the date/time from that field, when read from the zip file/stream.
> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>      and the last modified time set via the new method will also set 
> the "time",
>      and the getLastModifiedTime() also returns the "time", if the UTC 
> time
>      stamp fields are not set in the zip file header. The idea is that 
> for the new
>      application, the recommendation is to use 
> ZipEntry.set/getLastModifiedTime()
>      for better/correct time stamp, but the existing apps keep the 
> same behavior.
> (3) jar and ZipOutputStream are updated to use the 
> set/getLastModifiedTime().
> (4) Pack/unpack continues to use the set/getTime(), so the current 
> workaround
>      continues work. I will leave this to Kuma to decide how it should 
> be handled
>      going forward. (there are two facts need to be considered here, 
> a) the
>      existing jar file might not have the utc time instored, and b) 
> all "extra" data
>      are wiped out during the pack/unpacking process)
> (5) additionally add another pair of atime/get/setLastAccessTime and
>      ctime/get/setCreationTime().
> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the 
> "new"
>      nio FileTime, instead of the "long". This may add some additional 
> cost of
>      conversion when working with them, but may also help improve the
>      performance if the time stamps are directly from nio  file system 
> when
>      get/set XYZTime. Good/bad?
>
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>
> Comment, option and suggestion are appreciated.
At a high-level this looks a reasonable approach. An alternative would 
be to define an API over the extra block but I don't think we want to go 
there.

For consistency you might consider setTime setting mtime to null, 
otherwise the ordering when both setXXX methods are used is significant. 
Another thing to consider is whether the "parsing" of the extra block 
could be changed to being lazy now as it's only interesting when someone 
asks for it or the higher precision time stamps. Thinking back to the 
original changes then I wonder if we discussed the UNIX extra field, 
maybe you said that Windows tools can't handle such zip files?

A possible concern is that the footprint of ZipEntry increases. We could 
eliminate this increase if the new methods operated on the extra block. 
There's a clearly a trade-off here.

I spotted one or two "modificatin" in the javadoc, but I'll make time to 
do a proof-read the javadoc once the approach is agreed.

-Alan.






From brian.burkhalter at oracle.com  Fri Jun 21 15:04:46 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 21 Jun 2013 08:04:46 -0700
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C421A2.3080903@oracle.com>
References: 
	<51C421A2.3080903@oracle.com>
Message-ID: 


On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:

> One part that might need attention is getRadixConversionCache as I could imagine cases where the synchronization could lead to contention. Have you (or Alan) considered alternatives that would limit the synchronization to only when the powers cache needs to be expanded?

I have not but will do so. I cannot speak for Alan E.

Brian

From aleksey.shipilev at oracle.com  Fri Jun 21 15:36:51 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 21 Jun 2013 19:36:51 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
Message-ID: <51C47313.9080906@oracle.com>

On 06/21/2013 07:04 PM, Brian Burkhalter wrote:
> 
> On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
> 
>> One part that might need attention is getRadixConversionCache as I
>> could imagine cases where the synchronization could lead to
>> contention. Have you (or Alan) considered alternatives that would
>> limit the synchronization to only when the powers cache needs to be
>> expanded?
> 
> I have not but will do so. I cannot speak for Alan E.

That's actually quite straight-forward. Make the list immutable, put it
into the volatile reference; count the current size in volatile field.
You can then try to resize the cache concurrently by generating the new
list, and assigning it to the volatile reference. Since the resizes are
not frequent, you don't care if you compute multiple candidates with
multiple threads.

-Aleksey.


From xueming.shen at oracle.com  Fri Jun 21 15:41:23 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 21 Jun 2013 08:41:23 -0700
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
In-Reply-To: <51C45614.4010205@oracle.com>
References: <51C34E6D.4000502@oracle.com> <51C45614.4010205@oracle.com>
Message-ID: <51C47423.5070609@oracle.com>

On 6/21/13 6:33 AM, Alan Bateman wrote:
> On 20/06/2013 19:48, Xueming Shen wrote:
>> :
>>
>> I'm proposing the following approach to add the functionality of 
>> supporting
>> the "utc-date/time-with-1-second granularity" and keep the old behavior
>> of the get/setTime() of the ZipEntry.
>>
>> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
>>      To set via the old setTime() will only store the time into zip's 
>> standard
>>      date/time field, which is in MS-DOS date/time. And getTime() 
>> only returns
>>      the date/time from that field, when read from the zip file/stream.
>> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>>      and the last modified time set via the new method will also set 
>> the "time",
>>      and the getLastModifiedTime() also returns the "time", if the 
>> UTC time
>>      stamp fields are not set in the zip file header. The idea is 
>> that for the new
>>      application, the recommendation is to use 
>> ZipEntry.set/getLastModifiedTime()
>>      for better/correct time stamp, but the existing apps keep the 
>> same behavior.
>> (3) jar and ZipOutputStream are updated to use the 
>> set/getLastModifiedTime().
>> (4) Pack/unpack continues to use the set/getTime(), so the current 
>> workaround
>>      continues work. I will leave this to Kuma to decide how it 
>> should be handled
>>      going forward. (there are two facts need to be considered here, 
>> a) the
>>      existing jar file might not have the utc time instored, and b) 
>> all "extra" data
>>      are wiped out during the pack/unpacking process)
>> (5) additionally add another pair of atime/get/setLastAccessTime and
>>      ctime/get/setCreationTime().
>> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the 
>> "new"
>>      nio FileTime, instead of the "long". This may add some 
>> additional cost of
>>      conversion when working with them, but may also help improve the
>>      performance if the time stamps are directly from nio  file 
>> system when
>>      get/set XYZTime. Good/bad?
>>
>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>
>> Comment, option and suggestion are appreciated.
> At a high-level this looks a reasonable approach. An alternative would 
> be to define an API over the extra block but I don't think we want to 
> go there.
>
> For consistency you might consider setTime setting mtime to null, 
> otherwise the ordering when both setXXX methods are used is 
> significant. Another thing to consider is whether the "parsing" of the 
> extra block could be changed to being lazy now as it's only 
> interesting when someone asks for it or the higher precision time 
> stamps. Thinking back to the original changes then I wonder if we 
> discussed the UNIX extra field, maybe you said that Windows tools 
> can't handle such zip files?
>
> A possible concern is that the footprint of ZipEntry increases. We 
> could eliminate this increase if the new methods operated on the extra 
> block. There's a clearly a trade-off here.

I do have a version that set/getXYZTime() on extra data...but given the 
expectation is
the new methods will be recommended in new code shift away from the dos 
time, so
the extra will take some footprint of ZE as well...but yes, it may have 
the benefit of
saving at least the a/ctime, which normally people don't care. Another 
footprint concern
is the minimum 18 bytes increase (for mtime alone, in 9 for loc and 9 
for cen) for each
file in jar file, in case of rt.jar, it is relatively a big increase. A 
possible solution is to
have explicit API for ZOS and explicit command option for jar command to 
"turn" this
one explicitly by developer/user, instead of the default. Or, as an 
alternative to have
some mechanism to turn them off, if the size increase is not desired.

>
> I spotted one or two "modificatin" in the javadoc, but I'll make time 
> to do a proof-read the javadoc once the approach is agreed.
>
> -Alan.
>
>
>
>



From eliasen at mindspring.com  Fri Jun 21 16:56:42 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Fri, 21 Jun 2013 10:56:42 -0600
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
Message-ID: <51C485CA.80308@mindspring.com>

On 06/21/2013 09:04 AM, Brian Burkhalter wrote:
> 
> On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
> 
>> One part that might need attention is getRadixConversionCache as I
>> could imagine cases where the synchronization could lead to
>> contention. Have you (or Alan) considered alternatives that would
>> limit the synchronization to only when the powers cache needs to be
>> expanded?
> 
> I have not but will do so. I cannot speak for Alan E.

   Yes, as noted in the code comments and in my comments on this list,
it would be possible to do something fancier, perhaps using Future.
This code was intended to be as simple and understandable as possible,
to rapidly give an asymptotically much faster algorithm that would have
minimal review impact but significant performance improvement.  Other
design goals were to not duplicate work in the case that two threads
attempted to convert the same large number and calculate the same cache
value at the same time (this used to be a big problem before the pow()
function got much faster.  Some of those cache expansions required
hours, and you didn't want to do them twice.)

   There was also potential room for argument about the need for a cache
at all.  However, it became clear that keeping a cache significantly
improved performance at the cost of holding on to some memory with the
idea that if you print one big number, you're likely going to print
another big number at some time during the life of the VM.

   It was also a goal at one point in the 11-year-history of this bug to
produce code that could be backported to previous Java versions, thus no
use of Future, etc.  That may no longer be necessary.  I don't know
about other Java profiles that might use this code.  I was asked for
small, simple patches that could be reviewed in stages, so that's
somewhat reflected in the simplicity of that code.  The caches are
extended rarely, so although that method may block, it should not block
for too long.  I'm willing to review any rewrites that people might
suggest.  Frankly, when I started looking at rewriting the cache using
Future, the code complexity and data structures got quite unwieldy very
quickly.  Especially when trying to eliminate duplicated effort.

   If profiling shows that this is a bottleneck, we can revise it, but I
didn't see evidence of that.  It was suggested to make some of these
algorithms multi-threaded, but that was soundly rejected on this list
for this phase.  Perhaps in a later phase when the algorithms become
multi-threaded, the cache can be revised.

   The Schoenhage recursive base conversion code is not triggered unless
numbers are already significantly largish, so it won't affect
performance of smaller numbers, but the algorithm's much-improved
efficiency will make it faster for the larger numbers that trigger it.

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From eric.mccorkle at oracle.com  Fri Jun 21 19:57:31 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 21 Jun 2013 15:57:31 -0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
Message-ID: <51C4B02B.7040004@oracle.com>

Hello, please review this patch which adds isNamePresent to the
java.lang.reflect.Parameter API.

The webrev is here:
http://cr.openjdk.java.net/~emc/8016285/

The change request is here:
http://bugs.sun.com/view_bug.do?bug_id=8016285

The updated spec is here:
http://cr.openjdk.java.net/~abuckley/8misc.pdf

Thanks,
Eric

From alan.bateman at oracle.com  Fri Jun 21 20:09:41 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 21 Jun 2013 20:09:41 +0000
Subject: hg: jdk8/tl/jdk: 7192954: Fix Float.parseFloat to round correctly and
	preserve monotonicity.; ...
Message-ID: <20130621201022.D85C0483F4@hg.openjdk.java.net>

Changeset: a88f6f4d279f
Author:    bpb
Date:      2013-06-21 11:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a88f6f4d279f

7192954: Fix Float.parseFloat to round correctly and preserve monotonicity.
4396272: Parsing doubles fails to follow IEEE for largest decimal that should yield 0
7039391: Use Math.ulp in FloatingDecimal
Summary: Correct rounding and monotonicity problems in floats and doubles
Reviewed-by: bpb, martin
Contributed-by: Dmitry Nadezhin , Louis Wasserman 

! src/share/classes/sun/misc/FDBigInteger.java
! src/share/classes/sun/misc/FloatingDecimal.java
! test/java/lang/Double/ParseDouble.java
! test/java/lang/Float/ParseFloat.java
! test/sun/misc/FloatingDecimal/TestFDBigInteger.java



From aleksey.shipilev at oracle.com  Fri Jun 21 20:15:58 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sat, 22 Jun 2013 00:15:58 +0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
In-Reply-To: <51C4B02B.7040004@oracle.com>
References: <51C4B02B.7040004@oracle.com>
Message-ID: <51C4B47E.4060702@oracle.com>

On 06/21/2013 11:57 PM, Eric McCorkle wrote:
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8016285/

Looks generally good (but not a Reviewer).

A few questions though:
  a) Are we em-bracing the brace-less control flow blocks?
  b) Should hasRealParameterData be transient?
  c) Should hasRealParameterData be volatile? (now is being implicitly
protected by $parameters volatile write/read, but it is fragile)

-Aleksey.



From alan.bateman at oracle.com  Fri Jun 21 20:28:22 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 21 Jun 2013 20:28:22 +0000
Subject: hg: jdk8/tl/jdk: 7131192: BigInteger.doubleValue() is depressingly
	slow
Message-ID: <20130621202835.A3114483F5@hg.openjdk.java.net>

Changeset: 814759462705
Author:    bpb
Date:      2013-06-21 11:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/814759462705

7131192: BigInteger.doubleValue() is depressingly slow
Summary: In doubleValue() and floatValue() replace converting to String and parsing to Double or Float with direct conversion into IEEE 754 bits.
Reviewed-by: bpb, drchase, martin
Contributed-by: Louis Wasserman 

! src/share/classes/java/math/BigInteger.java
+ test/java/math/BigInteger/PrimitiveConversionTests.java



From naoto.sato at oracle.com  Fri Jun 21 20:43:42 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 21 Jun 2013 20:43:42 +0000
Subject: hg: jdk8/tl/jdk: 6863624: java/util/Currency/PropertiesTest.sh
	writable check is incorrect
Message-ID: <20130621204354.25036483F8@hg.openjdk.java.net>

Changeset: 8b84d557570c
Author:    naoto
Date:      2013-06-21 13:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b84d557570c

6863624: java/util/Currency/PropertiesTest.sh writable check is incorrect
Reviewed-by: alanb

! test/java/util/Currency/PropertiesTest.sh
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh



From brian.burkhalter at oracle.com  Fri Jun 21 21:13:17 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 21 Jun 2013 14:13:17 -0700
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with
	precision 0 or 1 throws ArrayOutOfBoundsException
Message-ID: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>

Please review the patch

http://cr.openjdk.java.net/~bpb/6469160/

which fixes

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160

The problem affects only general formatting (%g) of zero values and the code is modified to handle zero as a special case.

Thanks,

Brian

From eric.mccorkle at oracle.com  Fri Jun 21 23:21:52 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Fri, 21 Jun 2013 19:21:52 -0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
In-Reply-To: <51C4B47E.4060702@oracle.com>
References: <51C4B02B.7040004@oracle.com> <51C4B47E.4060702@oracle.com>
Message-ID: <51C4E010.1050603@oracle.com>

On 06/21/13 16:15, Aleksey Shipilev wrote:
> On 06/21/2013 11:57 PM, Eric McCorkle wrote:
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8016285/
> 
> Looks generally good (but not a Reviewer).
> 
> A few questions though:
>   a) Are we em-bracing the brace-less control flow blocks?

Fixed it.

>   b) Should hasRealParameterData be transient?
>   c) Should hasRealParameterData be volatile? (now is being implicitly
> protected by $parameters volatile write/read, but it is fragile)

Transient yes.  Volatile, I'd say I think not, since It's written before
it's read on all possible paths, and all writes are the same value.
But...  I set it volatile just to be safe from reordering problems.

Webrev's been updated.
http://cr.openjdk.java.net/~emc/8016285/

From brian.burkhalter at oracle.com  Sat Jun 22 00:42:28 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 21 Jun 2013 17:42:28 -0700
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C485CA.80308@mindspring.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C485CA.80308@mindspring.com>
Message-ID: 

On Jun 21, 2013, at 9:56 AM, Alan Eliasen wrote:

>   Yes, as noted in the code comments and in my comments on this list,
> it would be possible to do something fancier, perhaps using Future.
> This code was intended to be as simple and understandable as possible,
> to rapidly give an asymptotically much faster algorithm that would have
> minimal review impact but significant performance improvement. [?]

Indeed it was important to simplify the review effort to get things moving.

>   [?] However, it became clear that keeping a cache significantly
> improved performance at the cost of holding on to some memory with the
> idea that if you print one big number, you're likely going to print
> another big number at some time during the life of the VM.

This seems like an eminently reasonable assumption.

>   [?]
> 
>   If profiling shows that this is a bottleneck, we can revise it, but I
> didn't see evidence of that.  It was suggested to make some of these
> algorithms multi-threaded, but that was soundly rejected on this list
> for this phase.  Perhaps in a later phase when the algorithms become
> multi-threaded, the cache can be revised.

As these patches had been stalled for so long it was my intent to streamline their being integrated in the Java 8 source base with the idea that once in place further refinements could be made. I think the main open problem for this patch and the Karatsuba one just integrated this week is to determine algorithm crossover thresholds which are not going to provoke performance degradations for certain intermediate bit lengths on the platforms of interest. Any suggestions on this topic would also be appreciated.

>   The Schoenhage recursive base conversion code is not triggered unless
> numbers are already significantly largish, so it won't affect
> performance of smaller numbers, but the algorithm's much-improved
> efficiency will make it faster for the larger numbers that trigger it.

This is an excellent point: improving the radix cache handling only affects the large number cases which will already be vastly faster that what would obtain without this patch.

Brian

From joe.darcy at oracle.com  Sat Jun 22 03:14:15 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 21 Jun 2013 20:14:15 -0700
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with
	precision 0 or 1 throws ArrayOutOfBoundsException
In-Reply-To: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
References: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
Message-ID: <51C51687.6080309@oracle.com>

Hi Brian,

What is the expected behavior on signed zero files? I think they should 
be added to the test cases.

-Joe

On 6/21/2013 2:13 PM, Brian Burkhalter wrote:
> Please review the patch
>
> http://cr.openjdk.java.net/~bpb/6469160/
>
> which fixes
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
>
> The problem affects only general formatting (%g) of zero values and the code is modified to handle zero as a special case.
>
> Thanks,
>
> Brian



From dmitry.nadezhin at gmail.com  Sat Jun 22 04:06:10 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 22 Jun 2013 08:06:10 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C47313.9080906@oracle.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
Message-ID: 

Alexey,

Each possible radix has its cacheLine in the cache.

Cache contents looks like
BigInteger[][] powerCache = new BigInteger[37] {
/*0*/ null,
/*1*/ null,
/*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
/*3*/ new BigInteger[] { 3, 9, 81, ... },
/*4*/ new BigInteger[] { 4, 16, 256, ... }
/*5*/ new BigInteger[] { 5, 25, 625, ... },
/*6*/ new BigInteger[] { 6 },
/*7*/ new BigInteger[] { 7 },
. . .
/*36*/ new BigInteger[] { 36 }
};

Is there an idiom for a list/array of volatile references ?
I am not sure that such naive code works:
volatile BigInteger[][] powerCache = ..,

  -Dima


On Fri, Jun 21, 2013 at 7:36 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 06/21/2013 07:04 PM, Brian Burkhalter wrote:
> >
> > On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
> >
> >> One part that might need attention is getRadixConversionCache as I
> >> could imagine cases where the synchronization could lead to
> >> contention. Have you (or Alan) considered alternatives that would
> >> limit the synchronization to only when the powers cache needs to be
> >> expanded?
> >
> > I have not but will do so. I cannot speak for Alan E.
>
> That's actually quite straight-forward. Make the list immutable, put it
> into the volatile reference; count the current size in volatile field.
> You can then try to resize the cache concurrently by generating the new
> list, and assigning it to the volatile reference. Since the resizes are
> not frequent, you don't care if you compute multiple candidates with
> multiple threads.
>
> -Aleksey.
>


From dmitry.nadezhin at gmail.com  Sat Jun 22 04:23:31 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 22 Jun 2013 08:23:31 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
Message-ID: 

Brian,

This patch significally enhances performance of string conversion  for
large numbers.

I suggest to create also a fast path for power-of-two radices: 2, 4, 8, 16,
32 .
It is a simple linear algorithm that is suitable both for large and small
numbers.
Can it be attached to this bug activity ?
Or should it be filed as another bug ?


On Wed, Jun 19, 2013 at 11:58 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Continuing on from this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018181.html
>
> here is a new Request for Review, this time for
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641897
>
> The webrev is here
>
> http://cr.openjdk.java.net/~bpb/4641897/
>
> The code changes have been reviewed by me and regression tests have been
> run on my development machine including the updated test which is in the
> webrev. Performance testing has been performed only insofar as to verify
> improvement at bit lengths much larger than the algorithm crossover
> threshold with the understanding that, as for 4837946 and 4646474, the
> threshold is subject to adjustment pending performance evaluation on a mix
> of platforms.
>
> Thanks,
>
> Brian


From eliasen at mindspring.com  Sat Jun 22 04:37:47 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Fri, 21 Jun 2013 22:37:47 -0600
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	
Message-ID: <51C52A1B.8030108@mindspring.com>

On 06/21/2013 10:23 PM, Dmitry Nadezhin wrote:
> Brian,
> 
> This patch significally enhances performance of string conversion  for
> large numbers.
> 
> I suggest to create also a fast path for power-of-two radices: 2, 4, 8, 16,
> 32 .
> It is a simple linear algorithm that is suitable both for large and small
> numbers.
> Can it be attached to this bug activity ?
> Or should it be filed as another bug ?

   I'd file it as another bug.

   As you'll see if you run profiling tests, and the power-of-two
radices are already *much* faster than the other powers, as would be
expected.  It's possible to do the power-of-two conversions completely
with bit operations in BigInteger and not relying on Long, but the
improvement may be small as these cases are already relatively fast.

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From eliasen at mindspring.com  Sat Jun 22 05:26:26 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Fri, 21 Jun 2013 23:26:26 -0600
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C485CA.80308@mindspring.com>
	
Message-ID: <51C53582.3090807@mindspring.com>

On 06/21/2013 06:42 PM, Brian Burkhalter wrote:
> I think
> the main open problem for this patch and the Karatsuba one just
> integrated this week is to determine algorithm crossover thresholds
> which are not going to provoke performance degradations for certain
> intermediate bit lengths on the platforms of interest. Any
> suggestions on this topic would also be appreciated.

   I'll send along some of the simple programs I used to tune the
thresholds for Karatsuba and Toom-Cook multiplication.  I posted these
 As has been stated before, tuning of these thresholds is as much of an
art as it is a science, as results will vary greatly for different bit
patterns.  You have to kind of weight toward the bit patterns that occur
most often in real-world programs (e.g powers of 2 +/-1, factorials, etc.)

   It would be great to have some sort of auto-tuner as part of the
build process, but of course that doesn't work when we're building
binary distributions that just get downloaded by end-users.
Arbitrary-precision math packages like GMP have a bunch of hard-coded
thresholds that are selected when your processor architecture is
detected, but if you want to work harder, you can run their autotune
programs to build headers that work well on your specific computer with
its unique cache sizes, memory speeds, etc.  Of course, you'll sometimes
see very different thresholds found when you run the tuning program
multiple times!  It's easy in C/C++ to do conditional #defines based on
detected processor architecture to get good performance, but I know
that's not the Java way.

   The thresholds I chose for the running program were found to work
well on a variety of Linux/Intel and Windows architectures, all the way
back to an 800 MHz Pentium III.  (Unfortunately, it's impossible to
build JDK 8 on those older systems due to its memory requirements.  One
of my semi-fast AMD-64 Linux systems still takes 21 hours to build JDK 8
due to excessive swap.  It could build JDK 7 much faster.)

    I set the thresholds intentionally conservative to work well on all
the architectures I have access to.  The thresholds could have been
moved lower on modern architectures, but with a slight possible impact
to older architectures.  In any case, the performance of the various
algorithms is nearly the same in the crossover regions, so it usually
doesn't matter all that much.

   However, I can see that it's quite possible that JVMs which have very
expensive memory allocation overhead, or where allocation contention is
high, could be impacted more severely, and might have to have their
thresholds adjusted.  It's probably impossible to find a fixed set of
thresholds that perform optimally on all platforms.

   My tuning programs require a fair amount of re-running and changing
of the arguments tested, and keeping track of the thresholds that work
well for all arguments.  Again, more of an art than a science.

   Here's what you have to do:

   1.)  In your JDK code, in BigInteger.java, make KARATSUBA_THRESHOLD
and TOOM_COOK_THRESHOLD "public" instead of "private final".  This
allows the tuning program to tweak them.  (Be sure to change this back
when you're done tuning!)

   2.) Recompile JDK

   3.) Compile BigIntTiming.java

    javac BigIntTiming.java

   4.) Run BigIntTiming to see which thresholds are fastest.  Keep track
of these.  Times are in milliseconds.  Smaller numbers are faster.  The
first column is the Karatsuba threshold, second column is the Toom-Cook
threshold.  (Note that these may need to be modified again when we add
Schoenhage-Strassen multiplication.)

    java BigIntTiming

   I usually start with multiplications of two (small) large numbers,
say 2^200000 * 3^100001, and then change the code to work with much
bigger numbers, e.g. 2^2000000 * 3^1000000 to exercise larger arguments.
  (That is, repeat steps 3) and 4) many times.)  Larger arguments will
test many smaller powers as the recursive algorithms break down the
multiplications into smaller and smaller numbers.   You will want to
change the bounds of the

   for (int i=1; i<20 ...

    loop to adjust to the time spent in various number sizes.  You want
the timings to be significant but not so long as to take forever.


    The code for the tuning program is available at:

    http://futureboy.us/temp/BigIntTiming.java

   Let me know what sort of thresholds you find to work best on various
architectures.

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From chris.hegarty at oracle.com  Sat Jun 22 07:22:14 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Sat, 22 Jun 2013 07:22:14 +0000
Subject: hg: jdk8/tl/jdk: 7157360: HttpURLConnection: HTTP method DELETE
	doesn't support output
Message-ID: <20130622072243.684C74841B@hg.openjdk.java.net>

Changeset: fd050ba1cf72
Author:    arieber
Date:      2013-06-22 08:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd050ba1cf72

7157360: HttpURLConnection: HTTP method DELETE doesn't support output
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/PosterOutputStream.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/http/HttpURLConnection/PostOnDelete.java



From chris.hegarty at oracle.com  Sat Jun 22 07:16:36 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Sat, 22 Jun 2013 07:16:36 +0000
Subject: hg: jdk8/tl/jdk: 8017271: Crash may occur in
	java.net.DualStackPlainSocketImpl::initIDs due to unchecked
	values returned from JNI functions
Message-ID: <20130622071713.3D5FC48419@hg.openjdk.java.net>

Changeset: cb3f3a05eee3
Author:    chegar
Date:      2013-06-22 08:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb3f3a05eee3

8017271: Crash may occur in java.net.DualStackPlainSocketImpl::initIDs due to unchecked values returned from JNI functions
Reviewed-by: alanb, khazra

! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/windows/native/java/net/DualStackPlainSocketImpl.c



From dmitry.nadezhin at gmail.com  Sat Jun 22 09:11:58 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 22 Jun 2013 13:11:58 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C52A1B.8030108@mindspring.com>
References: 
	
	<51C52A1B.8030108@mindspring.com>
Message-ID: 

Below are the results of performance evaluation:
1) Performance improvement of specialized method bi.toHexString() against
general bi.toString(16).
2) Code ot hypothetical BigInteger.toHexString();
3) Code of benchmark.

  -Dima

=== b.bitLength(); b.toString(16); b.toHexString();
bitLength=2047;    0.001458205 sec    3.11251E-4 sec
bitLength=4095;    0.003836644 sec    6.14027E-4 sec
bitLength=8191;    0.01112082 sec    0.001148153 sec
bitLength=16383;    0.009785916 sec    0.00256648 sec
bitLength=32767;    0.024226532 sec    0.005104734 sec
bitLength=65535;    0.040899736 sec    0.001239427 sec
bitLength=131071;    0.057398824 sec    0.002302767 sec
bitLength=262143;    0.13263946 sec    0.004272388 sec
bitLength=524287;    0.44488142 sec    8.64876E-4 sec
bitLength=1048575;    1.628629919 sec    0.001423972 sec
bitLength=2097151;    6.399754105 sec    0.002084977 sec
bitLength=4194303;    25.052650526 sec    0.004460035 sec
bitLength=8388607;    100.974373978 sec    0.009238686 sec
bitLength=16777215;    407.2107094 sec    0.018795085 sec
===

=== The code of BigInteger.toHexString()
    public String toHexString() {
        if (signum == 0) {
            return "0";
        }
        int highestLimb = mag[0];
        int digitsInHigherLimb = 8 -
Integer.numberOfLeadingZeros(highestLimb) / 4;
        int len = (mag.length - 1) * 8 + digitsInHigherLimb;
        if (signum < 0)
            len++;
        StringBuilder buf = new StringBuilder(len);
        if (signum<0)
            buf.append('-');
        for (int i = digitsInHigherLimb - 1; i >= 0; i--) {
            buf.append(Character.forDigit((highestLimb >> (i * 4)) & 0xF,
16));
        }
        for (int i = 1; i < mag.length; i++) {
            int m = mag[i];
            buf.append(Character.forDigit((m >> 28) & 0xF, 16));
            buf.append(Character.forDigit((m >> 24) & 0xF, 16));
            buf.append(Character.forDigit((m >> 20) & 0xF, 16));
            buf.append(Character.forDigit((m >> 16) & 0xF, 16));
            buf.append(Character.forDigit((m >> 12) & 0xF, 16));
            buf.append(Character.forDigit((m >> 8) & 0xF, 16));
            buf.append(Character.forDigit((m >> 4) & 0xF, 16));
            buf.append(Character.forDigit(m & 0xF, 16));
        }
        return buf.toString();
    }
===

=== The benchmark program
public class TestToString {

    public static void main(String[] args) {
        int n = 1;
        BigInteger bi = BigInteger.ONE;
        System.out.println("b.bitLength(); b.toString(16);
b.toHexString();");
        for (int i = 0; i <= 23; i++) {
            long time0 = System.nanoTime();
            String s1 = bi.toString(16);
            long time1 = System.nanoTime();
            String s2 = bi.toHexString();
            long time2 = System.nanoTime();
            assert s1.equals(s2);
            if (i >= 10) {
                System.out.println("bitLength=" + bi.bitLength() + ";\t" +
(time1 - time0) / 1e9 + " sec\t" + (time2 - time1) / 1e9 + " sec");
            }
            n *= 2;
            bi = bi.shiftLeft(n).add(bi);
        }
    }
}
====

On Sat, Jun 22, 2013 at 8:37 AM, Alan Eliasen wrote:

> On 06/21/2013 10:23 PM, Dmitry Nadezhin wrote:
> > Brian,
> >
> > This patch significally enhances performance of string conversion  for
> > large numbers.
> >
> > I suggest to create also a fast path for power-of-two radices: 2, 4, 8,
> 16,
> > 32 .
> > It is a simple linear algorithm that is suitable both for large and small
> > numbers.
> > Can it be attached to this bug activity ?
> > Or should it be filed as another bug ?
>
>    I'd file it as another bug.
>
>    As you'll see if you run profiling tests, and the power-of-two
> radices are already *much* faster than the other powers, as would be
> expected.  It's possible to do the power-of-two conversions completely
> with bit operations in BigInteger and not relying on Long, but the
> improvement may be small as these cases are already relatively fast.
>
> --
>   Alan Eliasen
>   eliasen at mindspring.com
>   http://futureboy.us/
>


From aleksey.shipilev at oracle.com  Sat Jun 22 10:50:26 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sat, 22 Jun 2013 14:50:26 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
Message-ID: <51C58172.9030209@oracle.com>

On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
> Alexey,
> 
> Each possible radix has its cacheLine in the cache.
> 
> Cache contents looks like
> BigInteger[][] powerCache = new BigInteger[37] {
> /*0*/ null,
> /*1*/ null,
> /*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
> /*3*/ new BigInteger[] { 3, 9, 81, ... },
> /*4*/ new BigInteger[] { 4, 16, 256, ... }
> /*5*/ new BigInteger[] { 5, 25, 625, ... },
> /*6*/ new BigInteger[] { 6 },
> /*7*/ new BigInteger[] { 7 },
> . . .
> /*36*/ new BigInteger[] { 36 }
> };
> 
> Is there an idiom for a list/array of volatile references ?

AtomicReferenceArray is your friend there. Although I'm not sure why you
need the list of volatile references in this case. Placing volatile to
the root reference resolves the race.

> I am not sure that such naive code works:
> volatile BigInteger[][] powerCache = ..,

Why wouldn't it work?

 volatile T[][] cache;

 T[] get(int index) {
    T[][] lc = cache;
    if (index >= lc.length) { // need resizing
       lc = generateNew(index << 1);
       cache = lc;
    }
    return lc[index];
 }

If you need to populate the 2nd level, then you have to have the final
volatile write to the $cache. The corresponding $cache volatile read
makes the update on 2nd level visible.

 T get(int index1, index2) {
    T[][] lc = cache;
    if (index1 >= lc.length) { // needs resizing
       lc = generateNewT2(index1 << 1);
       cache = lc;
    }
    T[] lt = lc[index2];
    if (index2 >= lt.length) { // needs resizing
       lt = generateNewT1(index2 << 1);
       lc[index2] = lt;
       cache = lc; // publish
    }
    return lt[index2];
 }


-Aleksey.


From aleksey.shipilev at oracle.com  Sat Jun 22 10:54:26 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sat, 22 Jun 2013 14:54:26 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C58172.9030209@oracle.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com>
Message-ID: <51C58262.6030403@oracle.com>

On 06/22/2013 02:50 PM, Aleksey Shipilev wrote:
> On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
>> Alexey,
>>
>> Each possible radix has its cacheLine in the cache.
>>
>> Cache contents looks like
>> BigInteger[][] powerCache = new BigInteger[37] {
>> /*0*/ null,
>> /*1*/ null,
>> /*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
>> /*3*/ new BigInteger[] { 3, 9, 81, ... },
>> /*4*/ new BigInteger[] { 4, 16, 256, ... }
>> /*5*/ new BigInteger[] { 5, 25, 625, ... },
>> /*6*/ new BigInteger[] { 6 },
>> /*7*/ new BigInteger[] { 7 },
>> . . .
>> /*36*/ new BigInteger[] { 36 }
>> };
>>
>> Is there an idiom for a list/array of volatile references ?
> 
> AtomicReferenceArray is your friend there. Although I'm not sure why you
> need the list of volatile references in this case. Placing volatile to
> the root reference resolves the race.
> 
>> I am not sure that such naive code works:
>> volatile BigInteger[][] powerCache = ..,
> 
> Why wouldn't it work?
> 
>  volatile T[][] cache;
> 
>  T[] get(int index) {
>     T[][] lc = cache;
>     if (index >= lc.length) { // need resizing
>        lc = generateNew(index << 1);
>        cache = lc;
>     }
>     return lc[index];
>  }
> 
> If you need to populate the 2nd level, then you have to have the final
> volatile write to the $cache. The corresponding $cache volatile read
> makes the update on 2nd level visible.
> 
>  T get(int index1, index2) {
>     T[][] lc = cache;
>     if (index1 >= lc.length) { // needs resizing
>        lc = generateNewT2(index1 << 1);
>        cache = lc;
>     }
>     T[] lt = lc[index2];
>     if (index2 >= lt.length) { // needs resizing
>        lt = generateNewT1(index2 << 1);
>        lc[index2] = lt;
>        cache = lc; // publish
>     }
>     return lt[index2];
>  }

Of course, there is a series of typos. Should instead be:

  T get(int index1, index2) {
     T[][] lc = cache;
     if (index1 >= lc.length) { // needs resizing
        lc = ((index1 << 1) + 1);
        cache = lc;
     }
     T[] lt = lc[index2];
     if (index2 >= lt.length) { // needs resizing
        lt = ((index2 << 1) + 1);
        lc[index1] = lt;
        cache = lc; // publish
     }
     return lt[index2];
  }

-Aleksey.


From dmitry.nadezhin at gmail.com  Sat Jun 22 11:59:20 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sat, 22 Jun 2013 15:59:20 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C58262.6030403@oracle.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
Message-ID: 

Thank you, Aleksey!

Alan said: "I'm willing to review any rewrites that people might suggest".

Here is a concretization of Aleksey's patch for Alan's review.

*** Alan's BigInteger.java
--- BigInteger.java patched according to Aleksey's advice
***************
*** 1038,1048 ****
      /**
       * The cache of powers of each radix.  This allows us to not have to
       * recalculate powers of radix^(2^n) more than once.  This speeds
       * Schoenhage recursive base conversion significantly.
       */
!     private static ArrayList[] powerCache;

      /** The cache of logarithms of radices for base conversion. */
      private static final double[] logCache;

      /** The natural log of 2.  This is used in computing cache indices. */
--- 1038,1048 ----
      /**
       * The cache of powers of each radix.  This allows us to not have to
       * recalculate powers of radix^(2^n) more than once.  This speeds
       * Schoenhage recursive base conversion significantly.
       */
!     private static volatile BigInteger[][] powerCache;

      /** The cache of logarithms of radices for base conversion. */
      private static final double[] logCache;

      /** The natural log of 2.  This is used in computing cache indices. */
***************
*** 1059,1076 ****
          /*
           * Initialize the cache of radix^(2^x) values used for base
conversion
           * with just the very first value.  Additional values will be
created
           * on demand.
           */
!         powerCache = (ArrayList[])
!             new ArrayList[Character.MAX_RADIX+1];
          logCache = new double[Character.MAX_RADIX+1];

          for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
          {
!             powerCache[i] = new ArrayList(1);
!             powerCache[i].add(BigInteger.valueOf(i));
              logCache[i] = Math.log(i);
          }
      }

      /**
--- 1059,1074 ----
          /*
           * Initialize the cache of radix^(2^x) values used for base
conversion
           * with just the very first value.  Additional values will be
created
           * on demand.
           */
!         powerCache = new BigInteger[Character.MAX_RADIX+1][];
          logCache = new double[Character.MAX_RADIX+1];

          for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
          {
!             powerCache[i] = new BigInteger[] { BigInteger.valueOf(i) };
              logCache[i] = Math.log(i);
          }
      }

      /**
***************
*** 3450,3473 ****
       * If this value doesn't already exist in the cache, it is added.
       * 
    
       * This could be changed to a more complicated caching method using
       * Future.
       */
!     private static synchronized BigInteger getRadixConversionCache(int
radix,
!                                                                    int
exponent) {
          BigInteger retVal = null;
!         ArrayList cacheLine = powerCache[radix];
!         int oldSize = cacheLine.size();
          if (exponent >= oldSize) {
!             cacheLine.ensureCapacity(exponent+1);
              for (int i=oldSize; i<=exponent; i++) {
!                 retVal = cacheLine.get(i-1).square();
!                 cacheLine.add(i, retVal);
              }
!         }
!         else
!             retVal = cacheLine.get(exponent);

          return retVal;
      }

      /* zero[i] is a string of i consecutive zeros. */
--- 3448,3471 ----
       * If this value doesn't already exist in the cache, it is added.
       * 
    
       * This could be changed to a more complicated caching method using
       * Future.
       */
!     private static BigInteger getRadixConversionCache(int radix, int
exponent) {
          BigInteger retVal = null;
!         BigInteger[][] pc = powerCache;
!         BigInteger[] cacheLine = pc[radix];
!         int oldSize = cacheLine.length;
          if (exponent >= oldSize) {
!             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
              for (int i=oldSize; i<=exponent; i++) {
!                 retVal = cacheLine[i-1].square();
!                 cacheLine[i] = retVal;
              }
!             powerCache = pc; // publish by writing volatile variable
!         } else
!             retVal = cacheLine[exponent];

          return retVal;
      }

      /* zero[i] is a string of i consecutive zeros. */


On Sat, Jun 22, 2013 at 2:54 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 06/22/2013 02:50 PM, Aleksey Shipilev wrote:
> > On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
> >> Alexey,
> >>
> >> Each possible radix has its cacheLine in the cache.
> >>
> >> Cache contents looks like
> >> BigInteger[][] powerCache = new BigInteger[37] {
> >> /*0*/ null,
> >> /*1*/ null,
> >> /*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
> >> /*3*/ new BigInteger[] { 3, 9, 81, ... },
> >> /*4*/ new BigInteger[] { 4, 16, 256, ... }
> >> /*5*/ new BigInteger[] { 5, 25, 625, ... },
> >> /*6*/ new BigInteger[] { 6 },
> >> /*7*/ new BigInteger[] { 7 },
> >> . . .
> >> /*36*/ new BigInteger[] { 36 }
> >> };
> >>
> >> Is there an idiom for a list/array of volatile references ?
> >
> > AtomicReferenceArray is your friend there. Although I'm not sure why you
> > need the list of volatile references in this case. Placing volatile to
> > the root reference resolves the race.
> >
> >> I am not sure that such naive code works:
> >> volatile BigInteger[][] powerCache = ..,
> >
> > Why wouldn't it work?
> >
> >  volatile T[][] cache;
> >
> >  T[] get(int index) {
> >     T[][] lc = cache;
> >     if (index >= lc.length) { // need resizing
> >        lc = generateNew(index << 1);
> >        cache = lc;
> >     }
> >     return lc[index];
> >  }
> >
> > If you need to populate the 2nd level, then you have to have the final
> > volatile write to the $cache. The corresponding $cache volatile read
> > makes the update on 2nd level visible.
> >
> >  T get(int index1, index2) {
> >     T[][] lc = cache;
> >     if (index1 >= lc.length) { // needs resizing
> >        lc = generateNewT2(index1 << 1);
> >        cache = lc;
> >     }
> >     T[] lt = lc[index2];
> >     if (index2 >= lt.length) { // needs resizing
> >        lt = generateNewT1(index2 << 1);
> >        lc[index2] = lt;
> >        cache = lc; // publish
> >     }
> >     return lt[index2];
> >  }
>
> Of course, there is a series of typos. Should instead be:
>
>   T get(int index1, index2) {
>      T[][] lc = cache;
>      if (index1 >= lc.length) { // needs resizing
>         lc = ((index1 << 1) + 1);
>         cache = lc;
>      }
>      T[] lt = lc[index2];
>      if (index2 >= lt.length) { // needs resizing
>         lt = ((index2 << 1) + 1);
>         lc[index1] = lt;
>         cache = lc; // publish
>      }
>      return lt[index2];
>   }
>
> -Aleksey.
>


From dmitry.nadezhin at gmail.com  Sun Jun 23 03:41:18 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Sun, 23 Jun 2013 07:41:18 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
	
Message-ID: 

Sorry, I missed line "pc[radix] = cacheLine;" in the method
"getRadixConversionCache();"
in the previous post.
Here is the corrected patch.
*** Alan Eliasen's BigInteger.java
--- BigInteger.java patched according to Aleksey's advice
***************
*** 1038,1048 ****
      /**
       * The cache of powers of each radix.  This allows us to not have to
       * recalculate powers of radix^(2^n) more than once.  This speeds
       * Schoenhage recursive base conversion significantly.
       */
!     private static ArrayList[] powerCache;

      /** The cache of logarithms of radices for base conversion. */
      private static final double[] logCache;

      /** The natural log of 2.  This is used in computing cache indices. */
--- 1038,1048 ----
      /**
       * The cache of powers of each radix.  This allows us to not have to
       * recalculate powers of radix^(2^n) more than once.  This speeds
       * Schoenhage recursive base conversion significantly.
       */
!     private static volatile BigInteger[][] powerCache;

      /** The cache of logarithms of radices for base conversion. */
      private static final double[] logCache;

      /** The natural log of 2.  This is used in computing cache indices. */
***************
*** 1059,1076 ****
          /*
           * Initialize the cache of radix^(2^x) values used for base
conversion
           * with just the very first value.  Additional values will be
created
           * on demand.
           */
!         powerCache = (ArrayList[])
!             new ArrayList[Character.MAX_RADIX+1];
          logCache = new double[Character.MAX_RADIX+1];

          for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
          {
!             powerCache[i] = new ArrayList(1);
!             powerCache[i].add(BigInteger.valueOf(i));
              logCache[i] = Math.log(i);
          }
      }

      /**
--- 1059,1074 ----
          /*
           * Initialize the cache of radix^(2^x) values used for base
conversion
           * with just the very first value.  Additional values will be
created
           * on demand.
           */
!         powerCache = new BigInteger[Character.MAX_RADIX+1][];
          logCache = new double[Character.MAX_RADIX+1];

          for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
          {
!             powerCache[i] = new BigInteger[] { BigInteger.valueOf(i) };
              logCache[i] = Math.log(i);
          }
      }

      /**
***************
*** 3450,3473 ****
       * If this value doesn't already exist in the cache, it is added.
       * 
    
       * This could be changed to a more complicated caching method using
       * Future.
       */
!     private static synchronized BigInteger getRadixConversionCache(int
radix,
!                                                                    int
exponent) {
          BigInteger retVal = null;
!         ArrayList cacheLine = powerCache[radix];
!         int oldSize = cacheLine.size();
          if (exponent >= oldSize) {
!             cacheLine.ensureCapacity(exponent+1);
              for (int i=oldSize; i<=exponent; i++) {
!                 retVal = cacheLine.get(i-1).square();
!                 cacheLine.add(i, retVal);
              }
!         }
!         else
!             retVal = cacheLine.get(exponent);

          return retVal;
      }

      /* zero[i] is a string of i consecutive zeros. */
--- 3448,3472 ----
       * If this value doesn't already exist in the cache, it is added.
       * 
    
       * This could be changed to a more complicated caching method using
       * Future.
       */
!     private static BigInteger getRadixConversionCache(int radix, int
exponent) {
          BigInteger retVal = null;
!         BigInteger[][] pc = powerCache; // volatile read
!         BigInteger[] cacheLine = pc[radix];
!         int oldSize = cacheLine.length;
          if (exponent >= oldSize) {
!             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
              for (int i=oldSize; i<=exponent; i++) {
!                 retVal = cacheLine[i-1].square();
!                 cacheLine[i] = retVal;
              }
!             pc[radix] = cacheLine;
!             powerCache = pc; // publish by volatile write
!         } else
!             retVal = cacheLine[exponent];

          return retVal;
      }

      /* zero[i] is a string of i consecutive zeros. */



On Sat, Jun 22, 2013 at 3:59 PM, Dmitry Nadezhin
wrote:

> Thank you, Aleksey!
>
> Alan said: "I'm willing to review any rewrites that people might suggest".
>
> Here is a concretization of Aleksey's patch for Alan's review.
>
> *** Alan's BigInteger.java
> --- BigInteger.java patched according to Aleksey's advice
> ***************
> *** 1038,1048 ****
>       /**
>        * The cache of powers of each radix.  This allows us to not have to
>        * recalculate powers of radix^(2^n) more than once.  This speeds
>        * Schoenhage recursive base conversion significantly.
>        */
> !     private static ArrayList[] powerCache;
>
>       /** The cache of logarithms of radices for base conversion. */
>       private static final double[] logCache;
>
>       /** The natural log of 2.  This is used in computing cache indices.
> */
> --- 1038,1048 ----
>       /**
>        * The cache of powers of each radix.  This allows us to not have to
>        * recalculate powers of radix^(2^n) more than once.  This speeds
>        * Schoenhage recursive base conversion significantly.
>        */
> !     private static volatile BigInteger[][] powerCache;
>
>       /** The cache of logarithms of radices for base conversion. */
>       private static final double[] logCache;
>
>       /** The natural log of 2.  This is used in computing cache indices.
> */
> ***************
> *** 1059,1076 ****
>           /*
>            * Initialize the cache of radix^(2^x) values used for base
> conversion
>            * with just the very first value.  Additional values will be
> created
>            * on demand.
>            */
> !         powerCache = (ArrayList[])
> !             new ArrayList[Character.MAX_RADIX+1];
>           logCache = new double[Character.MAX_RADIX+1];
>
>           for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
>           {
> !             powerCache[i] = new ArrayList(1);
> !             powerCache[i].add(BigInteger.valueOf(i));
>               logCache[i] = Math.log(i);
>           }
>       }
>
>       /**
> --- 1059,1074 ----
>           /*
>            * Initialize the cache of radix^(2^x) values used for base
> conversion
>            * with just the very first value.  Additional values will be
> created
>            * on demand.
>            */
> !         powerCache = new BigInteger[Character.MAX_RADIX+1][];
>           logCache = new double[Character.MAX_RADIX+1];
>
>           for (int i=Character.MIN_RADIX; i<=Character.MAX_RADIX; i++)
>           {
> !             powerCache[i] = new BigInteger[] { BigInteger.valueOf(i) };
>               logCache[i] = Math.log(i);
>           }
>       }
>
>       /**
> ***************
> *** 3450,3473 ****
>        * If this value doesn't already exist in the cache, it is added.
>        * 
    
>        * This could be changed to a more complicated caching method using
>        * Future.
>        */
> !     private static synchronized BigInteger getRadixConversionCache(int
> radix,
> !                                                                    int
> exponent) {
>           BigInteger retVal = null;
> !         ArrayList cacheLine = powerCache[radix];
> !         int oldSize = cacheLine.size();
>           if (exponent >= oldSize) {
> !             cacheLine.ensureCapacity(exponent+1);
>               for (int i=oldSize; i<=exponent; i++) {
> !                 retVal = cacheLine.get(i-1).square();
> !                 cacheLine.add(i, retVal);
>               }
> !         }
> !         else
> !             retVal = cacheLine.get(exponent);
>
>           return retVal;
>       }
>
>       /* zero[i] is a string of i consecutive zeros. */
> --- 3448,3471 ----
>        * If this value doesn't already exist in the cache, it is added.
>        * 
    
>        * This could be changed to a more complicated caching method using
>        * Future.
>        */
> !     private static BigInteger getRadixConversionCache(int radix, int
> exponent) {
>           BigInteger retVal = null;
> !         BigInteger[][] pc = powerCache;
> !         BigInteger[] cacheLine = pc[radix];
> !         int oldSize = cacheLine.length;
>           if (exponent >= oldSize) {
> !             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>               for (int i=oldSize; i<=exponent; i++) {
> !                 retVal = cacheLine[i-1].square();
> !                 cacheLine[i] = retVal;
>               }
> !             powerCache = pc; // publish by writing volatile variable
> !         } else
> !             retVal = cacheLine[exponent];
>
>           return retVal;
>       }
>
>       /* zero[i] is a string of i consecutive zeros. */
>
>
> On Sat, Jun 22, 2013 at 2:54 PM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>
>> On 06/22/2013 02:50 PM, Aleksey Shipilev wrote:
>> > On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
>> >> Alexey,
>> >>
>> >> Each possible radix has its cacheLine in the cache.
>> >>
>> >> Cache contents looks like
>> >> BigInteger[][] powerCache = new BigInteger[37] {
>> >> /*0*/ null,
>> >> /*1*/ null,
>> >> /*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
>> >> /*3*/ new BigInteger[] { 3, 9, 81, ... },
>> >> /*4*/ new BigInteger[] { 4, 16, 256, ... }
>> >> /*5*/ new BigInteger[] { 5, 25, 625, ... },
>> >> /*6*/ new BigInteger[] { 6 },
>> >> /*7*/ new BigInteger[] { 7 },
>> >> . . .
>> >> /*36*/ new BigInteger[] { 36 }
>> >> };
>> >>
>> >> Is there an idiom for a list/array of volatile references ?
>> >
>> > AtomicReferenceArray is your friend there. Although I'm not sure why you
>> > need the list of volatile references in this case. Placing volatile to
>> > the root reference resolves the race.
>> >
>> >> I am not sure that such naive code works:
>> >> volatile BigInteger[][] powerCache = ..,
>> >
>> > Why wouldn't it work?
>> >
>> >  volatile T[][] cache;
>> >
>> >  T[] get(int index) {
>> >     T[][] lc = cache;
>> >     if (index >= lc.length) { // need resizing
>> >        lc = generateNew(index << 1);
>> >        cache = lc;
>> >     }
>> >     return lc[index];
>> >  }
>> >
>> > If you need to populate the 2nd level, then you have to have the final
>> > volatile write to the $cache. The corresponding $cache volatile read
>> > makes the update on 2nd level visible.
>> >
>> >  T get(int index1, index2) {
>> >     T[][] lc = cache;
>> >     if (index1 >= lc.length) { // needs resizing
>> >        lc = generateNewT2(index1 << 1);
>> >        cache = lc;
>> >     }
>> >     T[] lt = lc[index2];
>> >     if (index2 >= lt.length) { // needs resizing
>> >        lt = generateNewT1(index2 << 1);
>> >        lc[index2] = lt;
>> >        cache = lc; // publish
>> >     }
>> >     return lt[index2];
>> >  }
>>
>> Of course, there is a series of typos. Should instead be:
>>
>>   T get(int index1, index2) {
>>      T[][] lc = cache;
>>      if (index1 >= lc.length) { // needs resizing
>>         lc = ((index1 << 1) + 1);
>>         cache = lc;
>>      }
>>      T[] lt = lc[index2];
>>      if (index2 >= lt.length) { // needs resizing
>>         lt = ((index2 << 1) + 1);
>>         lc[index1] = lt;
>>         cache = lc; // publish
>>      }
>>      return lt[index2];
>>   }
>>
>> -Aleksey.
>>
>
>


From weijun.wang at oracle.com  Mon Jun 24 04:57:19 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 24 Jun 2013 12:57:19 +0800
Subject: sun/awt/OSInfo.java
Message-ID: <51C7D1AF.1000603@oracle.com>

I thought os.name for Solaris is 'Solaris' but it's actually 'SunOS'. 
There is a helper class at

 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/fd050ba1cf72/src/share/classes/sun/awt/OSInfo.java

This file uses

   if (osName.contains("Solaris") || osName.contains("SunOS"))

Is it real that the value can be 'Solaris' also?

Can we use this class or make a copy (or move it) into sun.misc?

Thanks
Max



From Alan.Bateman at oracle.com  Mon Jun 24 08:13:11 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Jun 2013 09:13:11 +0100
Subject: sun/awt/OSInfo.java
In-Reply-To: <51C7D1AF.1000603@oracle.com>
References: <51C7D1AF.1000603@oracle.com>
Message-ID: <51C7FF97.1020503@oracle.com>

On 24/06/2013 05:57, Weijun Wang wrote:
> I thought os.name for Solaris is 'Solaris' but it's actually 'SunOS'. 
> There is a helper class at
>
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/fd050ba1cf72/src/share/classes/sun/awt/OSInfo.java 
>
>
> This file uses
>
>   if (osName.contains("Solaris") || osName.contains("SunOS"))
>
> Is it real that the value can be 'Solaris' also?
>
> Can we use this class or make a copy (or move it) into sun.misc?

It's always been "SunOS".

Can you provide more context? The problem with adding or moving things 
to sun.misc is that it gets really hard to change or remove things later.

-Alan


From weijun.wang at oracle.com  Mon Jun 24 08:23:07 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 24 Jun 2013 16:23:07 +0800
Subject: sun/awt/OSInfo.java
In-Reply-To: <51C7FF97.1020503@oracle.com>
References: <51C7D1AF.1000603@oracle.com> <51C7FF97.1020503@oracle.com>
Message-ID: <51C801EB.2080604@oracle.com>

I don't meant to add any API for external users, but even JDK itself 
needs some helper classes, and looks like sun.misc is the place.

In this case, there are too many places inside JDK that checks what the 
current OS is. Some uses startsWith and some contains, some toLowerCase 
and some toUppreCase, some might not be complete (no OS X?). It will be 
nice if we have a safe and consistent way. It could even cover the 
PropertyPermission needed.

--Max

On 6/24/13 4:13 PM, Alan Bateman wrote:
> On 24/06/2013 05:57, Weijun Wang wrote:
>> I thought os.name for Solaris is 'Solaris' but it's actually 'SunOS'.
>> There is a helper class at
>>
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/fd050ba1cf72/src/share/classes/sun/awt/OSInfo.java
>>
>>
>> This file uses
>>
>>   if (osName.contains("Solaris") || osName.contains("SunOS"))
>>
>> Is it real that the value can be 'Solaris' also?
>>
>> Can we use this class or make a copy (or move it) into sun.misc?
>
> It's always been "SunOS".
>
> Can you provide more context? The problem with adding or moving things
> to sun.misc is that it gets really hard to change or remove things later.
>
> -Alan


From weijun.wang at oracle.com  Mon Jun 24 08:25:42 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 24 Jun 2013 08:25:42 +0000
Subject: hg: jdk8/tl/jdk: 8017453: ReplayCache tests fail on multiple platforms
Message-ID: <20130624082605.6C29248442@hg.openjdk.java.net>

Changeset: 1bf060029a5d
Author:    weijun
Date:      2013-06-24 16:25 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1bf060029a5d

8017453: ReplayCache tests fail on multiple platforms
Reviewed-by: xuelei

! test/sun/security/krb5/auto/ReplayCacheExpunge.java
! test/sun/security/krb5/auto/ReplayCacheTestProc.java



From alan.bateman at oracle.com  Mon Jun 24 10:31:02 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 24 Jun 2013 10:31:02 +0000
Subject: hg: jdk8/tl/jdk: 8017477: Remove TimeZone.DisplayNames, no longer used
Message-ID: <20130624103144.2524748444@hg.openjdk.java.net>

Changeset: 5f80b8cee601
Author:    alanb
Date:      2013-06-24 11:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f80b8cee601

8017477: Remove TimeZone.DisplayNames, no longer used
Reviewed-by: okutsu

! src/share/classes/java/util/TimeZone.java



From Alan.Bateman at oracle.com  Mon Jun 24 10:52:45 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Jun 2013 11:52:45 +0100
Subject: sun/awt/OSInfo.java
In-Reply-To: <51C801EB.2080604@oracle.com>
References: <51C7D1AF.1000603@oracle.com> <51C7FF97.1020503@oracle.com>
	<51C801EB.2080604@oracle.com>
Message-ID: <51C824FD.5000604@oracle.com>

On 24/06/2013 09:23, Weijun Wang wrote:
> I don't meant to add any API for external users, but even JDK itself 
> needs some helper classes, and looks like sun.misc is the place.
>
> In this case, there are too many places inside JDK that checks what 
> the current OS is. Some uses startsWith and some contains, some 
> toLowerCase and some toUppreCase, some might not be complete (no OS 
> X?). It will be nice if we have a safe and consistent way. It could 
> even cover the PropertyPermission needed.
I agree we need to be consistent in the JDK. It might be interesting to 
look at the various usages to see whether they are really justified, 
maybe some of these usages are hints that the code in question needs to 
be refactored into platform specific code? Maybe this is just a reminder 
that src/solaris/classes needs an overhaul?

There is a lot of things in sun.misc that should be moved or removed but 
going anything seems to break things outside of the JDK. In recent 
times, we've started to put things into jdk.internal (I think of it as 
the "new" sun.misc).

-Alan.


From Alan.Bateman at oracle.com  Mon Jun 24 11:17:42 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Jun 2013 12:17:42 +0100
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
Message-ID: <51C82AD6.3060906@oracle.com>

On 21/06/2013 16:04, Brian Burkhalter wrote:
>
> On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
>
>> One part that might need attention is getRadixConversionCache as I 
>> could imagine cases where the synchronization could lead to 
>> contention. Have you (or Alan) considered alternatives that would 
>> limit the synchronization to only when the powers cache needs to be 
>> expanded?
>
> I have not but will do so. I cannot speak for Alan E.
>
"static synchronized" always jumps out but since every toString uses it 
when beyond the threshold then it would be good to eliminate. You're 
doing great work to sequence all these patches and if fixing this now 
delays the plan then it would be fine to address it later.

-Alan


From huizhe.wang at oracle.com  Mon Jun 24 17:33:20 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 24 Jun 2013 10:33:20 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
Message-ID: <51C882E0.9030006@oracle.com>

Hi,

Does anyone know if it's possible to automate a test with a 3rd party 
jar file on the bootclasspath or java.endorsed.dirs?

I have a test that I run manually with Apache Xerces jar.

Thanks,
Joe


-------- Original Message --------
Subject: 	[JBS] (JDK-8016773) Regression: diff. behavior with 
user-defined SAXParser
Date: 	Mon, 24 Jun 2013 17:04:02 +0000 (UTC)
From: 	Pavel Stepanov (JBS) 
To: 	huizhe.wang at oracle.com



Pavel Stepanov 
 
commented on Backport JDK-8016773 

*Regression: diff. behavior with user-defined SAXParser* 



	
so, does this mean it is impossible to write regresion test?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA 
administrators 
.
For more information on JIRA, see: http://www.atlassian.com/software/jira





From brian.burkhalter at oracle.com  Mon Jun 24 18:04:36 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jun 2013 11:04:36 -0700
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with
	precision 0 or 1 throws ArrayOutOfBoundsException
In-Reply-To: <51C51687.6080309@oracle.com>
References: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
	<51C51687.6080309@oracle.com>
Message-ID: 

Hi Joe,

On Jun 21, 2013, at 8:14 PM, Joe Darcy wrote:

> Hi Brian,
> 
> What is the expected behavior on signed zero files?

I assume you intend "values."

> I think they should be added to the test cases.

Done starting at line 1180 here:

http://cr.openjdk.java.net/~bpb/6469160/test/java/util/Formatter/Basic-X.java.template.html

Thanks,

Brian

> -Joe
> 
> On 6/21/2013 2:13 PM, Brian Burkhalter wrote:
>> Please review the patch
>> 
>> http://cr.openjdk.java.net/~bpb/6469160/
>> 
>> which fixes
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
>> 
>> The problem affects only general formatting (%g) of zero values and the code is modified to handle zero as a special case.
>> 
>> Thanks,
>> 
>> Brian



From iris.clark at oracle.com  Mon Jun 24 18:22:48 2013
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 24 Jun 2013 11:22:48 -0700 (PDT)
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with
	precision 0 or 1 throws ArrayOutOfBoundsException
In-Reply-To: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
References: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
Message-ID: 

Hi, Brian.

Your changes look good to me.

Thanks,
iris
(original code author, not a Reviewer)

-----Original Message-----
From: Brian Burkhalter 
Sent: Friday, June 21, 2013 2:13 PM
To: Java Core Libs
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException

Please review the patch

http://cr.openjdk.java.net/~bpb/6469160/

which fixes

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160

The problem affects only general formatting (%g) of zero values and the code is modified to handle zero as a special case.

Thanks,

Brian


From peter.levart at gmail.com  Mon Jun 24 18:23:59 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 24 Jun 2013 20:23:59 +0200
Subject: 7122142 : (ann) Race condition between isAnnotationPresent and
	getAnnotations
In-Reply-To: <51C1FE64.3020000@oracle.com>
References: <51C1BEC6.1080308@gmail.com> <51C1FE64.3020000@oracle.com>
Message-ID: <51C88EBF.9020704@gmail.com>

On 06/19/2013 08:54 PM, Alan Bateman wrote:
> Thank you for coming back to this.
>
> I've looked over the webrev and the approach looks good to me. Joel 
> might want to look at this too. Do you think you could include a test 
> (as we try to include a test with all fixes if we can)?
>
> It would be good to remove the synchronizaiton on 
> initAnnotationsIfNecessary too, but one step as time (and smaller 
> changes are always easier to discuss).
>
> -Alan

Hi Alan,

I have prepared the 2nd revision of the patch:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.02/

There is a little change in AnnotationParser's alternative parsing 
method. This time the parser does not assume anything about annotations 
being parsed (previously it assumed that they had RUNTIME retention). 
The only difference from standard parsing is that only the select 
annotation types are parsed and the rest are quickly skipped. Infinite 
recursion is broken by the special cased evaluation in AnnotationType 
constructor:

  129         // Initialize retention, & inherited fields.  Special treatment
  130         // of the corresponding annotation types breaks infinite recursion.
  131         if (annotationClass != Retention.class &&
  132             annotationClass != Inherited.class) {
  133             JavaLangAccess jla = sun.misc.SharedSecrets.getJavaLangAccess();
  134             Map, Annotation> metaAnnotations =
  135                 AnnotationParser.parseAnnotations(
  136                     jla.getRawClassAnnotations(annotationClass),
  137                     jla.getConstantPool(annotationClass),
  138                     annotationClass,
  139                     Retention.class, Inherited.class
  140                 );
  141             Retention ret = (Retention) metaAnnotations.get(Retention.class);
  142             retention = (ret == null ? RetentionPolicy.CLASS : ret.value());
  143             inherited = metaAnnotations.containsKey(Inherited.class);
  144         }
  145         else {
  146             retention = RetentionPolicy.RUNTIME;
  147             inherited = false;
  148         }


This is enough to break recursion. The RUNTIME and !inherited 
assumptions for @Retention and @Inherited meta-annotations are therefore 
localized in this code only.

I have also added two tests. The one for detecting deadlock situation 
and the other for consistent parsing of mutually recursive annotations 
in presence of separate compilation.



Regards, Peter



From eric.mccorkle at oracle.com  Mon Jun 24 19:20:32 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Mon, 24 Jun 2013 15:20:32 -0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
In-Reply-To: <51C4E010.1050603@oracle.com>
References: <51C4B02B.7040004@oracle.com> <51C4B47E.4060702@oracle.com>
	<51C4E010.1050603@oracle.com>
Message-ID: <51C89C00.20604@oracle.com>

Pinging this RFR.  It still needs a capital R reviewer.
http://cr.openjdk.java.net/~emc/8016285/

On 06/21/13 19:21, Eric McCorkle wrote:
> On 06/21/13 16:15, Aleksey Shipilev wrote:
>> On 06/21/2013 11:57 PM, Eric McCorkle wrote:
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8016285/
>>
>> Looks generally good (but not a Reviewer).
>>
>> A few questions though:
>>   a) Are we em-bracing the brace-less control flow blocks?
> 
> Fixed it.
> 
>>   b) Should hasRealParameterData be transient?
>>   c) Should hasRealParameterData be volatile? (now is being implicitly
>> protected by $parameters volatile write/read, but it is fragile)
> 
> Transient yes.  Volatile, I'd say I think not, since It's written before
> it's read on all possible paths, and all writes are the same value.
> But...  I set it volatile just to be safe from reordering problems.
> 
> Webrev's been updated.
> http://cr.openjdk.java.net/~emc/8016285/
> 

From sean.coffey at oracle.com  Mon Jun 24 19:50:19 2013
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Mon, 24 Jun 2013 20:50:19 +0100
Subject: test with a 3rd party jar file?
In-Reply-To: <51C882E0.9030006@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com>
Message-ID: <51C8A2FB.4030805@oracle.com>

You should be able to do it with scripts. Mandy designed something 
similar recently :

http://opengrok.ie.oracle.com:8080/opengrok/xref/jdk7u-cpu/jdk/test/closed/java/util/logging/SystemLoggerTest.sh

In the recent infrastructure meeting, scripts for tests were frowned 
upon. I don't see any alternative unless jtreg is able to handle this 
relatively simple (common?) setup request.

regards,
Sean.


On 24/06/13 18:33, huizhe wang wrote:
> Hi,
>
> Does anyone know if it's possible to automate a test with a 3rd party 
> jar file on the bootclasspath or java.endorsed.dirs?
>
> I have a test that I run manually with Apache Xerces jar.
>
> Thanks,
> Joe
>
>
> -------- Original Message --------
> Subject:     [JBS] (JDK-8016773) Regression: diff. behavior with 
> user-defined SAXParser
> Date:     Mon, 24 Jun 2013 17:04:02 +0000 (UTC)
> From:     Pavel Stepanov (JBS) 
> To:     huizhe.wang at oracle.com
>
>
>
> Pavel Stepanov 
>  
> commented on Backport JDK-8016773 
> 
> *Regression: diff. behavior with user-defined SAXParser* 
> 
>
>
>
> so, does this mean it is impossible to write regresion test?
>
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA 
> administrators 
> .
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>



From brian.burkhalter at oracle.com  Mon Jun 24 19:56:17 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jun 2013 12:56:17 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
Message-ID: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>

This issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178739

exposes what could be either a minor specification or implementation flaw depending on one's interpretation. The test case is

public class TestFormat {
    public static void main(String argv[]) {
        System.out.printf("%1.4f\n", 56789.456789);
        System.out.printf("%0.4f\n", 56789.456789); // java.util.MissingFormatWidthException
    }
}

The format specification applicable to the "%f" conversion is

%[argument_index$][flag][width][.precision]conversion

The problem comes in because, according to the specification,

1) zero (0) is a legal flag which indicates that the output should be zero-padded, and
2) width is a non-negative value indicating the minimum number of characters to be printed.

The outcome is that the format string which provokes the exception above could be seen to be ambiguous: it could be interpreted to mean either that the output is zero-padded or that the minimum number of characters to print is zero. If one however uses the format string "%00.4f\n" to indicate zero padding and zero width it provokes a java.util.DuplicateFormatFlagsException.

By way of comparison, this C code

    printf("%1.4f\n", 56789.456789F);
    printf("%0.4f\n", 56789.456789F);

prints this output

56789.4570
56789.4570

and providing the format string "%00.4f" is a compilation error.

This result appears to assume a default width of zero for the zero-padded case which seems to be reasonable behavior, but it is precluded for the Formatter by the javadoc for the zero-padding flag:

"Requires the output to be padded with leading zeros to the minimum field width following any sign or radix indicator except when converting NaN or infinity. If the width is not provided, then a MissingFormatWidthException will be thrown."

Comments?

Brian

From mandy.chung at oracle.com  Mon Jun 24 19:55:28 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 24 Jun 2013 12:55:28 -0700
Subject: Review Request 8007035: Deprecate SecurityManager.checkMemberAccess
Message-ID: <51C8A430.4050409@oracle.com>

I have updated the fix per the discussion in [1]. 
SecurityManager.checkMemberAccess will be deprecated and will check for 
AllPermission in a future release.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/webrev.01/

Specdiff:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8007035/specdiff/overview-summary.html

Thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-March/015547.html


From joe.darcy at oracle.com  Mon Jun 24 20:53:14 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 24 Jun 2013 13:53:14 -0700
Subject: RFR 6469160: (fmt) general (%g) formatting of zero (0.0) with
	precision 0 or 1 throws ArrayOutOfBoundsException
In-Reply-To: 
References: <431C2071-E867-4948-8992-A93162AEBE1F@oracle.com>
	<51C51687.6080309@oracle.com>
	
Message-ID: <51C8B1BA.20205@oracle.com>

Hi Brian,

On 6/24/2013 11:04 AM, Brian Burkhalter wrote:
> Hi Joe,
>
> On Jun 21, 2013, at 8:14 PM, Joe Darcy wrote:
>
>> Hi Brian,
>>
>> What is the expected behavior on signed zero files?
> I assume you intend "values."

Correct :-)

>
>> I think they should be added to the test cases.
> Done starting at line 1180 here:
>
> http://cr.openjdk.java.net/~bpb/6469160/test/java/util/Formatter/Basic-X.java.template.html

Look good; thanks,

-Joe

>
> Thanks,
>
> Brian
>
>> -Joe
>>
>> On 6/21/2013 2:13 PM, Brian Burkhalter wrote:
>>> Please review the patch
>>>
>>> http://cr.openjdk.java.net/~bpb/6469160/
>>>
>>> which fixes
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
>>>
>>> The problem affects only general formatting (%g) of zero values and the code is modified to handle zero as a special case.
>>>
>>> Thanks,
>>>
>>> Brian



From howard.lovatt at gmail.com  Thu Jun 20 07:24:46 2013
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Thu, 20 Jun 2013 17:24:46 +1000
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
In-Reply-To: <518524C1.5010203@CoSoCo.de>
References: 
	<5E833D21-CF16-4468-809E-5569964C85B8@oracle.com>
	<518524C1.5010203@CoSoCo.de>
Message-ID: 

I would say not needed, !isNull() is sufficient. If included isNotNull() is
the better name.


On 5 May 2013 01:09, Ulf Zibis  wrote:

>
> Am 04.05.2013 04:28, schrieb Mike Duigou:
> > I have updated the webrev to include incorporate the feedback I have
> received.
> >
> > http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/
> >
> > Regarding the naming of the "nonNull" method. I originally added this
> method in 2011 but I've forgotten since then why it has the name it does.
> As best as I can determine the name is either derived from the the name
> used by Guava for the same predicate, "notNull", or the names derives from
> the name "requireNonNull" in that this method doesn't require that the
> reference be non-null. The EG hasn't been concerned that this method
> doesn't use the "is" prefix.
>
> Do we need nonNull/isNotNull() at all, as it's always !isNull()?
> Anyway I would prefer isNotNull().
>
> -Ulf
>
>
>


-- 
  -- Howard.


From jack at moxley.co.uk  Thu Jun 20 07:36:32 2013
From: jack at moxley.co.uk (Jack Moxley)
Date: Thu, 20 Jun 2013 08:36:32 +0100
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
In-Reply-To: 
References: 
	<5E833D21-CF16-4468-809E-5569964C85B8@oracle.com>
	<518524C1.5010203@CoSoCo.de>
	
Message-ID: 

Really depends about whether you want the method to be bad English, or really bad English. :-). All this double negativity gets me down. What's wrong with exists() ?

Sent from my iPhone

On 20 Jun 2013, at 08:24, Howard Lovatt  wrote:

> I would say not needed, !isNull() is sufficient. If included isNotNull() is
> the better name.
> 
> 
> On 5 May 2013 01:09, Ulf Zibis  wrote:
> 
>> 
>> Am 04.05.2013 04:28, schrieb Mike Duigou:
>>> I have updated the webrev to include incorporate the feedback I have
>> received.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8013712/1/webrev/
>>> 
>>> Regarding the naming of the "nonNull" method. I originally added this
>> method in 2011 but I've forgotten since then why it has the name it does.
>> As best as I can determine the name is either derived from the the name
>> used by Guava for the same predicate, "notNull", or the names derives from
>> the name "requireNonNull" in that this method doesn't require that the
>> reference be non-null. The EG hasn't been concerned that this method
>> doesn't use the "is" prefix.
>> 
>> Do we need nonNull/isNotNull() at all, as it's always !isNull()?
>> Anyway I would prefer isNotNull().
>> 
>> -Ulf
> 
> 
> -- 
>  -- Howard.
> 



From per at bothner.com  Wed Jun 12 17:23:26 2013
From: per at bothner.com (Per Bothner)
Date: Wed, 12 Jun 2013 10:23:26 -0700
Subject: RFR 8009736: Comparator API cleanup
In-Reply-To: <51B790E6.6020209@oracle.com>
References: <51B790E6.6020209@oracle.com>
Message-ID: <51B8AE8E.6020703@bothner.com>

You might find interesting this proposal for "big" Scheme.
It views a "comparator" as a bundle consisting of an (optional)
comparator function, along with optional hash function,
equality function, and type-check function.

http://trac.sacrideo.us/wg/wiki/ComparatorsCowan

Using a more general "comparator bundle" can be
convenient at times.  For example when constructing
a hash table it is useful to pass the equality
function and the hash function as single object.
(Of course you normally don't use the compare
functions in those cases.)

If the ComparatorsCowan becomes part of Scheme,
I'd probably implement it as a class that implements
java.util.Comparator, at least for bundles that
have an actual compare function.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/


From mailforanubhav at gmail.com  Sun Jun 16 10:51:51 2013
From: mailforanubhav at gmail.com (Anubhav Chaturvedi)
Date: Sun, 16 Jun 2013 16:21:51 +0530
Subject: Inefficient code of String.indexOf(String)
Message-ID: 

Hello,

I have recently started to explore the source code and am new to the open
source community. I observed that in String.class within java.lang , the
indexOf method, line 1715, uses the bruteforce approach when it comes to
string matching. This method is used by the contains(CharSequence) method.
There are a number of algorithms that can perform the task more efficiently.

I would like to bring the required changes and needed your advice on this.

-- 
*Regards,*
*Anubhav Chaturvedi*

*Birla Institute of Technology & Science, Pilani*
KK Birla Goa Campus
+91-9637399150


From aleksey.shipilev at oracle.com  Mon Jun 24 21:28:46 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 01:28:46 +0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
In-Reply-To: <51C89C00.20604@oracle.com>
References: <51C4B02B.7040004@oracle.com> <51C4B47E.4060702@oracle.com>
	<51C4E010.1050603@oracle.com> <51C89C00.20604@oracle.com>
Message-ID: <51C8BA0E.7040109@oracle.com>

Forgot to reply: I'm ok with webrev.01.

-Aleksey
(rural r reviewer)

On 06/24/2013 11:20 PM, Eric McCorkle wrote:
> Pinging this RFR.  It still needs a capital R reviewer.
> http://cr.openjdk.java.net/~emc/8016285/
> 
> On 06/21/13 19:21, Eric McCorkle wrote:
>> On 06/21/13 16:15, Aleksey Shipilev wrote:
>>> On 06/21/2013 11:57 PM, Eric McCorkle wrote:
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~emc/8016285/
>>>
>>> Looks generally good (but not a Reviewer).
>>>
>>> A few questions though:
>>>   a) Are we em-bracing the brace-less control flow blocks?
>>
>> Fixed it.
>>
>>>   b) Should hasRealParameterData be transient?
>>>   c) Should hasRealParameterData be volatile? (now is being implicitly
>>> protected by $parameters volatile write/read, but it is fragile)
>>
>> Transient yes.  Volatile, I'd say I think not, since It's written before
>> it's read on all possible paths, and all writes are the same value.
>> But...  I set it volatile just to be safe from reordering problems.
>>
>> Webrev's been updated.
>> http://cr.openjdk.java.net/~emc/8016285/
>>



From rob.mckenna at oracle.com  Mon Jun 24 22:42:20 2013
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 24 Jun 2013 23:42:20 +0100
Subject: test with a 3rd party jar file?
In-Reply-To: <51C8A2FB.4030805@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
Message-ID: <51C8CB4C.90604@oracle.com>

Some interesting conversations were had lately about shell scripts 
during Joe Darcy's recent infrastructure tech talk. In particular around 
the idea of a "jdk.testing" package to provide libraries that would help 
with the types of operations seen in shell scripts. I'm really hoping to 
spend some time on this myself over the coming weeks. (in an effort to 
at least understand why we need shell scripts and whether we could do 
something else instead)

In any case it should be possible to simply replace the script with a 
java program that does the same thing. That would require fiddling with 
Process however, and its debatable as to whether that would result in 
fewer test failures. (shell scripts counting for a proportionally large 
number of those failures) JSR199 might help to reduce the amount of 
ProcessBuilders required in this instance.

     -Rob

On 24/06/13 20:50, Se?n Coffey wrote:
> You should be able to do it with scripts. Mandy designed something 
> similar recently :
>
> http://opengrok.ie.oracle.com:8080/opengrok/xref/jdk7u-cpu/jdk/test/closed/java/util/logging/SystemLoggerTest.sh 
>
>
> In the recent infrastructure meeting, scripts for tests were frowned 
> upon. I don't see any alternative unless jtreg is able to handle this 
> relatively simple (common?) setup request.
>
> regards,
> Sean.
>
>
> On 24/06/13 18:33, huizhe wang wrote:
>> Hi,
>>
>> Does anyone know if it's possible to automate a test with a 3rd party 
>> jar file on the bootclasspath or java.endorsed.dirs?
>>
>> I have a test that I run manually with Apache Xerces jar.
>>
>> Thanks,
>> Joe
>>
>>
>> -------- Original Message --------
>> Subject:     [JBS] (JDK-8016773) Regression: diff. behavior with 
>> user-defined SAXParser
>> Date:     Mon, 24 Jun 2013 17:04:02 +0000 (UTC)
>> From:     Pavel Stepanov (JBS) 
>> To:     huizhe.wang at oracle.com
>>
>>
>>
>> Pavel Stepanov 
>>  
>> commented on Backport JDK-8016773 
>> 
>> *Regression: diff. behavior with user-defined SAXParser* 
>> 
>>
>>
>>
>> so, does this mean it is impossible to write regresion test?
>>
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA 
>> administrators 
>> .
>> For more information on JIRA, see: 
>> http://www.atlassian.com/software/jira
>>
>>
>>
>



From naoto.sato at oracle.com  Mon Jun 24 23:22:23 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 24 Jun 2013 23:22:23 +0000
Subject: hg: jdk8/tl/jdk: 8017468: typo in javadoc: " ResourceBunlde "
Message-ID: <20130624232245.F2ECE4849B@hg.openjdk.java.net>

Changeset: bb2e67628dc0
Author:    naoto
Date:      2013-06-24 16:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2e67628dc0

8017468: typo in javadoc: " ResourceBunlde "
Reviewed-by: okutsu

! src/share/classes/java/util/spi/LocaleServiceProvider.java



From brian.burkhalter at oracle.com  Mon Jun 24 23:29:53 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jun 2013 16:29:53 -0700
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: 
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
	
	
Message-ID: <18072355-A813-4434-BCD0-CDDFFE45E310@oracle.com>

So I am going to try to please everybody (I hope).

I agree with Alan Eliasen that the existing patch for 4641897 should be integrated as-is.

I also think however that we might as well integrate Aleksey and Dima's patch immediately thereafter, before the large integer division review. To that end I am creating a separate issue and RFR which I will post today. It would be good if any other interested parties were to review it.

Thanks,

Brian

On Jun 24, 2013, at 4:17 AM, Alan Bateman wrote:

> "static synchronized" always jumps out but since every toString uses it when beyond the threshold then it would be good to eliminate. You're doing great work to sequence all these patches and if fixing this now delays the plan then it would be fine to address it later.

On Jun 22, 2013, at 8:41 PM, Dmitry Nadezhin wrote:

> Sorry, I missed line "pc[radix] = cacheLine;" in the method
> "getRadixConversionCache();"
> in the previous post.
> Here is the corrected patch.

On Jun 22, 2013, at 4:59 AM, Dmitry Nadezhin wrote:

> Thank you, Aleksey!
> 
> Alan said: "I'm willing to review any rewrites that people might suggest".
>  
> Here is a concretization of Aleksey's patch for Alan's review.


On Jun 22, 2013, at 3:54 AM, Aleksey Shipilev wrote:

> Of course, there is a series of typos. Should instead be:
> 
>  T get(int index1, index2) {
>     [?]
>     return lt[index2];
>  }


On Jun 21, 2013, at 9:37 PM, Alan Eliasen wrote:

>> Or should it be filed as another bug ?
> 
>   I'd file it as another bug.


From brian.burkhalter at oracle.com  Mon Jun 24 23:53:12 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Jun 2013 16:53:12 -0700
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
Message-ID: 

Branching off from this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html

I filed this issue (should be public tomorrow)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540

for the getRadixConversionCache() enhancement. The patch is here

http://cr.openjdk.java.net/~bpb/8017540/

I reviewed and tested the code for correctness and see no issues, so to speak. This patch cannot be integrated prior to that for 4641897.

Thanks,

Brian

From dan.xu at oracle.com  Tue Jun 25 00:17:32 2013
From: dan.xu at oracle.com (Dan Xu)
Date: Mon, 24 Jun 2013 17:17:32 -0700
Subject: RFR JDK-8017212 - File.createTempFile requires unnecessary "read"
	permission
Message-ID: <51C8E19C.4010205@oracle.com>

HiAll,

The fix of JDK-8013827 added an unnecessary "read" permission 
requirement in File.createTempFile methods. This change is going to fix 
this issue. Please help review it. Thanks!


webrev: http://cr.openjdk.java.net/~dxu/8017212/webrev.00/
bug: http://bugs.sun.com/view_bug.do?bug_id=8017212

-Dan


From huizhe.wang at oracle.com  Tue Jun 25 00:51:49 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 24 Jun 2013 17:51:49 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <51C8CB4C.90604@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com>
Message-ID: <51C8E9A5.8010002@oracle.com>

Thanks Sean and Rob.

Yes, I was told before to avoid shell scripts in tests. I'll wait till 
after your investigation to see what's the best to do in this case.

-Joe

On 6/24/2013 3:42 PM, Rob McKenna wrote:
> Some interesting conversations were had lately about shell scripts 
> during Joe Darcy's recent infrastructure tech talk. In particular 
> around the idea of a "jdk.testing" package to provide libraries that 
> would help with the types of operations seen in shell scripts. I'm 
> really hoping to spend some time on this myself over the coming weeks. 
> (in an effort to at least understand why we need shell scripts and 
> whether we could do something else instead)
>
> In any case it should be possible to simply replace the script with a 
> java program that does the same thing. That would require fiddling 
> with Process however, and its debatable as to whether that would 
> result in fewer test failures. (shell scripts counting for a 
> proportionally large number of those failures) JSR199 might help to 
> reduce the amount of ProcessBuilders required in this instance.
>
>     -Rob
>
> On 24/06/13 20:50, Se?n Coffey wrote:
>> You should be able to do it with scripts. Mandy designed something 
>> similar recently :
>>
>> http://opengrok.ie.oracle.com:8080/opengrok/xref/jdk7u-cpu/jdk/test/closed/java/util/logging/SystemLoggerTest.sh 
>>
>>
>> In the recent infrastructure meeting, scripts for tests were frowned 
>> upon. I don't see any alternative unless jtreg is able to handle this 
>> relatively simple (common?) setup request.
>>
>> regards,
>> Sean.
>>
>>
>> On 24/06/13 18:33, huizhe wang wrote:
>>> Hi,
>>>
>>> Does anyone know if it's possible to automate a test with a 3rd 
>>> party jar file on the bootclasspath or java.endorsed.dirs?
>>>
>>> I have a test that I run manually with Apache Xerces jar.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>> -------- Original Message --------
>>> Subject:     [JBS] (JDK-8016773) Regression: diff. behavior with 
>>> user-defined SAXParser
>>> Date:     Mon, 24 Jun 2013 17:04:02 +0000 (UTC)
>>> From:     Pavel Stepanov (JBS) 
>>> To:     huizhe.wang at oracle.com
>>>
>>>
>>>
>>> Pavel Stepanov 
>>>  
>>> commented on Backport JDK-8016773 
>>> 
>>> *Regression: diff. behavior with user-defined SAXParser* 
>>> 
>>>
>>>
>>>
>>> so, does this mean it is impossible to write regresion test?
>>>
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA 
>>> administrators 
>>> .
>>> For more information on JIRA, see: 
>>> http://www.atlassian.com/software/jira
>>>
>>>
>>>
>>
>



From weijun.wang at oracle.com  Tue Jun 25 01:05:51 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 25 Jun 2013 09:05:51 +0800
Subject: test with a 3rd party jar file?
In-Reply-To: <51C8CB4C.90604@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com>
Message-ID: <51C8ECEF.6080200@oracle.com>

On 6/25/13 6:42 AM, Rob McKenna wrote:
> Some interesting conversations were had lately about shell scripts
> during Joe Darcy's recent infrastructure tech talk. In particular around
> the idea of a "jdk.testing" package to provide libraries that would help
> with the types of operations seen in shell scripts. I'm really hoping to
> spend some time on this myself over the coming weeks. (in an effort to
> at least understand why we need shell scripts and whether we could do
> something else instead)

Oh, I've recently invented a new wheel on loading processes and make 
them interact with each other

 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java

An example here

 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java

--Max

>
>      -Rob
>


From eric.mccorkle at oracle.com  Tue Jun 25 02:05:16 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Tue, 25 Jun 2013 02:05:16 +0000
Subject: hg: jdk8/tl/langtools: 8012722: Single comma in array initializer
	should parse
Message-ID: <20130625020522.E3E9E484C2@hg.openjdk.java.net>

Changeset: bf020de5a6db
Author:    emc
Date:      2013-06-24 22:03 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf020de5a6db

8012722: Single comma in array initializer should parse
Summary: Annotations of the form @Foo({,}) should parse
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/SingleCommaAnnotationValue.java
+ test/tools/javac/parser/SingleCommaAnnotationValueFail.java
+ test/tools/javac/parser/SingleCommaAnnotationValueFail.out



From joe.darcy at oracle.com  Tue Jun 25 04:25:47 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 24 Jun 2013 21:25:47 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
Message-ID: <51C91BCB.70707@oracle.com>

On 6/24/2013 12:56 PM, Brian Burkhalter wrote:
> This issue
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178739
>
> exposes what could be either a minor specification or implementation flaw depending on one's interpretation. The test case is
>
> public class TestFormat {
>      public static void main(String argv[]) {
>          System.out.printf("%1.4f\n", 56789.456789);
>          System.out.printf("%0.4f\n", 56789.456789); // java.util.MissingFormatWidthException
>      }
> }
>
> The format specification applicable to the "%f" conversion is
>
> %[argument_index$][flag][width][.precision]conversion
>
> The problem comes in because, according to the specification,
>
> 1) zero (0) is a legal flag which indicates that the output should be zero-padded, and
> 2) width is a non-negative value indicating the minimum number of characters to be printed.
>
> The outcome is that the format string which provokes the exception above could be seen to be ambiguous: it could be interpreted to mean either that the output is zero-padded or that the minimum number of characters to print is zero. If one however uses the format string "%00.4f\n" to indicate zero padding and zero width it provokes a java.util.DuplicateFormatFlagsException.
>
> By way of comparison, this C code
>
>      printf("%1.4f\n", 56789.456789F);
>      printf("%0.4f\n", 56789.456789F);
>
> prints this output
>
> 56789.4570
> 56789.4570
>
> and providing the format string "%00.4f" is a compilation error.
>
> This result appears to assume a default width of zero for the zero-padded case which seems to be reasonable behavior, but it is precluded for the Formatter by the javadoc for the zero-padding flag:
>
> "Requires the output to be padded with leading zeros to the minimum field width following any sign or radix indicator except when converting NaN or infinity. If the width is not provided, then a MissingFormatWidthException will be thrown."
>
> Comments?
>

As a point of comparison, how does the C specification of printf and how 
do C implementations handle this combination?

-Joe



From dan.xu at oracle.com  Tue Jun 25 03:55:36 2013
From: dan.xu at oracle.com (dan.xu at oracle.com)
Date: Tue, 25 Jun 2013 03:55:36 +0000
Subject: hg: jdk8/tl/jdk: 6469160: (fmt) general (%g) formatting of zero (0.0)
	with precision 0 or 1 throws ArrayOutOfBoundsException
Message-ID: <20130625035557.91738484C7@hg.openjdk.java.net>

Changeset: eabcb85fcabc
Author:    bpb
Date:      2013-06-24 14:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eabcb85fcabc

6469160: (fmt) general (%g) formatting of zero (0.0) with precision 0 or 1 throws ArrayOutOfBoundsException
Summary: For zero value ensure than an unpadded zero character is passed to Formatter.addZeros()
Reviewed-by: iris, darcy
Contributed-by: Brian Burkhalter 

! src/share/classes/java/util/Formatter.java
! src/share/classes/sun/misc/FloatingDecimal.java
! test/java/util/Formatter/Basic-X.java.template
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/BasicBigDecimal.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



From joe.darcy at oracle.com  Tue Jun 25 06:40:42 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 25 Jun 2013 06:40:42 +0000
Subject: hg: jdk8/tl/jdk: 8017550: Fix doclint issues in java.lang and
	subpackages
Message-ID: <20130625064122.AEE10484D2@hg.openjdk.java.net>

Changeset: 82e7682c17e2
Author:    darcy
Date:      2013-06-24 23:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e7682c17e2

8017550: Fix doclint issues in java.lang and subpackages
Reviewed-by: alanb, chegar

! src/share/classes/java/lang/Boolean.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/Short.java
! src/share/classes/java/lang/StrictMath.java
! src/share/classes/java/lang/SuppressWarnings.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/annotation/Annotation.java
! src/share/classes/java/lang/annotation/Repeatable.java
! src/share/classes/java/lang/annotation/Retention.java
! src/share/classes/java/lang/annotation/Target.java
! src/share/classes/java/lang/reflect/AnnotatedElement.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/java/lang/reflect/TypeVariable.java



From dmitry.nadezhin at gmail.com  Tue Jun 25 07:48:18 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Tue, 25 Jun 2013 11:48:18 +0400
Subject: What is the range of BigInteger values ?
Message-ID: 

Primitive integer types have well-specified value ranges
byte  [ -pow(2,7) , pow(2,7) )
short [ -pow(2,15) , pow(2,15) )
int   [ -pow(2,31) , pow(2,31) )
long  [ -pow(2,63) , pow(2,63) ) .

Primitive operations on these types wrap-around in case of overflow,
but there are methods which throws ArithmeticExceptions in case of overflow
like
static int Math.addExact(int x, int y) .

BigInteger type represents "arbitrary-precision integers".
BigInteger operation don't wrap-around.
However, it is an illusion that range of BigInteger values is unbounded.
Nothing in computer is unbounded.
Let's explore the BigInteger range.

The magnitude of BigInteger is stored in int[] array.
Number of element in array doesn't exceed pow(2,31) - 1.
Each element contaons 32 bits.
So the range of BigInteger is surely contained in
( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).

However, there are methods that may return invalid
results on very large BigInteger values:
int BigInteger.bitLength();
int BigInteger.bitCount();
int BigInteger.getLowestSetBit();
They return primitive "int" values, so they can't return
numbers larger then Integer.MAX_VALUE .

The method BigInteger.bitLength() returns correct result
for BigInteger values in the range
[ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) .
The methods bitCount() and getLowestSetBit() also return
correct result in this range.

I recollect this issue because:
1) The asymptotic time of BigInteger operations became
better after Alan Eliasen's changes, so huge BigInteger
values are more likely to appear in user programs;
2) I found a call of bitLength() method in the line BigInteger.java:3431
of this WebRev
http://cr.openjdk.java.net/~bpb/4641897/

I see a few options with this issue:
1) Specify that range of BigInteger is
[ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
and throw an ArithmeticException() on attempt to construct values out of
this range .

2) Keep the range unrestricted
( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
Define new methods
long BigInteger.bitLengthLong();
long BigInteger.bitCountLong();
long BigInteger.getLowestSetBitLong();
Deprecate
int BigInteger.bitLength();
int BigInteger.bitCount();
int BigInteger.getLowestSetBit();
Verify all other BigInteger methods that they are correct on huge values.

3) Keep the range unrestricted
( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
Methods
int BigInteger.bitLength();
int BigInteger.bitCount();
int BigInteger.getLowestSetBit();
throw Exception on huge values
Verify all other BigInteger methods that they are correct on huge values.

My preference is (1).


From dmitry.nadezhin at gmail.com  Tue Jun 25 08:33:46 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Tue, 25 Jun 2013 12:33:46 +0400
Subject: What is the range of BigInteger values ?
In-Reply-To: 
References: 
Message-ID: 

Correction.
The unrestricted BigInteger range is
( -pow(2, (pow(2,31) - 1)*32) , pow(2, (pow(2,31) - 1)*32) )
instead of
( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).

The restricted BigInteger range
[ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
is ok.



On Tue, Jun 25, 2013 at 11:48 AM, Dmitry Nadezhin  wrote:

> Primitive integer types have well-specified value ranges
> byte  [ -pow(2,7) , pow(2,7) )
> short [ -pow(2,15) , pow(2,15) )
> int   [ -pow(2,31) , pow(2,31) )
> long  [ -pow(2,63) , pow(2,63) ) .
>
> Primitive operations on these types wrap-around in case of overflow,
> but there are methods which throws ArithmeticExceptions in case of overflow
> like
> static int Math.addExact(int x, int y) .
>
> BigInteger type represents "arbitrary-precision integers".
> BigInteger operation don't wrap-around.
> However, it is an illusion that range of BigInteger values is unbounded.
> Nothing in computer is unbounded.
> Let's explore the BigInteger range.
>
> The magnitude of BigInteger is stored in int[] array.
> Number of element in array doesn't exceed pow(2,31) - 1.
> Each element contaons 32 bits.
> So the range of BigInteger is surely contained in
> ( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
>
> However, there are methods that may return invalid
> results on very large BigInteger values:
> int BigInteger.bitLength();
> int BigInteger.bitCount();
> int BigInteger.getLowestSetBit();
> They return primitive "int" values, so they can't return
> numbers larger then Integer.MAX_VALUE .
>
> The method BigInteger.bitLength() returns correct result
> for BigInteger values in the range
> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) ) .
> The methods bitCount() and getLowestSetBit() also return
> correct result in this range.
>
> I recollect this issue because:
> 1) The asymptotic time of BigInteger operations became
> better after Alan Eliasen's changes, so huge BigInteger
> values are more likely to appear in user programs;
> 2) I found a call of bitLength() method in the line BigInteger.java:3431
> of this WebRev
> http://cr.openjdk.java.net/~bpb/4641897/
>
> I see a few options with this issue:
> 1) Specify that range of BigInteger is
> [ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
> and throw an ArithmeticException() on attempt to construct values out of
> this range .
>
> 2) Keep the range unrestricted
> ( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
> Define new methods
> long BigInteger.bitLengthLong();
> long BigInteger.bitCountLong();
> long BigInteger.getLowestSetBitLong();
> Deprecate
> int BigInteger.bitLength();
> int BigInteger.bitCount();
> int BigInteger.getLowestSetBit();
> Verify all other BigInteger methods that they are correct on huge values.
>
> 3) Keep the range unrestricted
> ( -pow(2, pow(2,31) + 31) , pow(2, pow(2,31) + 31).
> Methods
> int BigInteger.bitLength();
> int BigInteger.bitCount();
> int BigInteger.getLowestSetBit();
> throw Exception on huge values
> Verify all other BigInteger methods that they are correct on huge values.
>
> My preference is (1).
>


From aleksey.shipilev at oracle.com  Tue Jun 25 08:40:28 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 12:40:28 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
Message-ID: <51C9577C.4000301@oracle.com>

On 06/25/2013 03:53 AM, Brian Burkhalter wrote:
> http://cr.openjdk.java.net/~bpb/8017540/

Thanks! Looks good to me.

Rather minor silly nit:

    cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
    for (int i = oldSize; i <= exponent; i++) {

...is probably more consistent as:

    cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
    for (int i = oldSize; i < exponent + 1; i++) {

This sets up easier subexpression elimination, and also "1" is now
clearly acts as the "prefetch distance". Although this is the slowpath
anyway, and does not really matter.

-Aleksey.
(the rural r reviewer)


From aleksey.shipilev at oracle.com  Tue Jun 25 09:00:56 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 13:00:56 +0400
Subject: RFR (XS) CR 8014233: java.lang.Thread should have @Contended
	on TLR fields
In-Reply-To: <51BED035.30300@oracle.com>
References: <51BED035.30300@oracle.com>
Message-ID: <51C95C48.7040203@oracle.com>

On 06/17/2013 01:00 PM, Aleksey Shipilev wrote:
> This is the respin of the RFE filed a month ago:
>   http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
> 
> The webrev is here:
>   http://cr.openjdk.java.net/~shade/8014233/webrev.02/

The changeset is here:
  http://cr.openjdk.java.net/~shade/8014233/8014233.changeset

I did a scrub for the reviewers from this and the previous thread. David
Holmes and Doug Lea were OK with the same patch in the previous thread,
so I put them into the Reviewed-by as well.

-Aleksey.



From peter.levart at gmail.com  Tue Jun 25 10:06:20 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 12:06:20 +0200
Subject: @CallerSensitive in Java SE 7u25
Message-ID: <51C96B9C.3070305@gmail.com>

Hi Mandy,

I noticed the @CallerSensitive annotation and machinery behind it has 
been back-ported to JDK7. That was when one of my apps using 
sun.reflect.Reflection.getCallerClass(int) failed. The native method 
taking "int" was deprecated, but it also changed the behavior. If I run 
the following program:

import sun.reflect.Reflection;

public class GetCallerClassTest {

     static class Tester {
         static void test(int frames) {
             System.out.println(frames + ": " + 
Reflection.getCallerClass(frames));
         }
     }

     public static void main(String[] args) {
         Tester.test(0);
         Tester.test(1);
         Tester.test(2);
         Tester.test(3);
     }
}


with JDK7u21, I get the following output:

0: class sun.reflect.Reflection
1: class GetCallerClassTest$Tester
2: class GetCallerClassTest
3: null


with JDK7u25, I get the following output:

0: class sun.reflect.Reflection
1: class sun.reflect.Reflection
2: class GetCallerClassTest$Tester
3: class GetCallerClassTest


It seems that with 7u25 the result is "shifted"  for one calling frame. 
Is that behavior change intentional to encourage people to "get off that 
wagon"?

Regards, Peter



From chris.hegarty at oracle.com  Tue Jun 25 10:14:21 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 25 Jun 2013 11:14:21 +0100
Subject: @CallerSensitive in Java SE 7u25
In-Reply-To: <51C96B9C.3070305@gmail.com>
References: <51C96B9C.3070305@gmail.com>
Message-ID: <51C96D7D.8020002@oracle.com>

Known issue, Mandy has a fix in progress [1].

-Chris.

[1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html

On 06/25/2013 11:06 AM, Peter Levart wrote:
> Hi Mandy,
>
> I noticed the @CallerSensitive annotation and machinery behind it has
> been back-ported to JDK7. That was when one of my apps using
> sun.reflect.Reflection.getCallerClass(int) failed. The native method
> taking "int" was deprecated, but it also changed the behavior. If I run
> the following program:
>
> import sun.reflect.Reflection;
>
> public class GetCallerClassTest {
>
>      static class Tester {
>          static void test(int frames) {
>              System.out.println(frames + ": " +
> Reflection.getCallerClass(frames));
>          }
>      }
>
>      public static void main(String[] args) {
>          Tester.test(0);
>          Tester.test(1);
>          Tester.test(2);
>          Tester.test(3);
>      }
> }
>
>
> with JDK7u21, I get the following output:
>
> 0: class sun.reflect.Reflection
> 1: class GetCallerClassTest$Tester
> 2: class GetCallerClassTest
> 3: null
>
>
> with JDK7u25, I get the following output:
>
> 0: class sun.reflect.Reflection
> 1: class sun.reflect.Reflection
> 2: class GetCallerClassTest$Tester
> 3: class GetCallerClassTest
>
>
> It seems that with 7u25 the result is "shifted"  for one calling frame.
> Is that behavior change intentional to encourage people to "get off that
> wagon"?
>
> Regards, Peter
>


From peter.levart at gmail.com  Tue Jun 25 10:19:52 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 12:19:52 +0200
Subject: @CallerSensitive in Java SE 7u25
In-Reply-To: <51C96D7D.8020002@oracle.com>
References: <51C96B9C.3070305@gmail.com> <51C96D7D.8020002@oracle.com>
Message-ID: <51C96EC8.4080209@gmail.com>

Hi Chris,

I see it now, thanks.

Regards, Peter

On 06/25/2013 12:14 PM, Chris Hegarty wrote:
> Known issue, Mandy has a fix in progress [1].
>
> -Chris.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
>
> On 06/25/2013 11:06 AM, Peter Levart wrote:
>> Hi Mandy,
>>
>> I noticed the @CallerSensitive annotation and machinery behind it has
>> been back-ported to JDK7. That was when one of my apps using
>> sun.reflect.Reflection.getCallerClass(int) failed. The native method
>> taking "int" was deprecated, but it also changed the behavior. If I run
>> the following program:
>>
>> import sun.reflect.Reflection;
>>
>> public class GetCallerClassTest {
>>
>>      static class Tester {
>>          static void test(int frames) {
>>              System.out.println(frames + ": " +
>> Reflection.getCallerClass(frames));
>>          }
>>      }
>>
>>      public static void main(String[] args) {
>>          Tester.test(0);
>>          Tester.test(1);
>>          Tester.test(2);
>>          Tester.test(3);
>>      }
>> }
>>
>>
>> with JDK7u21, I get the following output:
>>
>> 0: class sun.reflect.Reflection
>> 1: class GetCallerClassTest$Tester
>> 2: class GetCallerClassTest
>> 3: null
>>
>>
>> with JDK7u25, I get the following output:
>>
>> 0: class sun.reflect.Reflection
>> 1: class sun.reflect.Reflection
>> 2: class GetCallerClassTest$Tester
>> 3: class GetCallerClassTest
>>
>>
>> It seems that with 7u25 the result is "shifted"  for one calling frame.
>> Is that behavior change intentional to encourage people to "get off that
>> wagon"?
>>
>> Regards, Peter
>>



From Alan.Bateman at oracle.com  Tue Jun 25 10:24:02 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Jun 2013 11:24:02 +0100
Subject: @CallerSensitive in Java SE 7u25
In-Reply-To: <51C96B9C.3070305@gmail.com>
References: <51C96B9C.3070305@gmail.com>
Message-ID: <51C96FC2.2040200@oracle.com>

On 25/06/2013 11:06, Peter Levart wrote:
> :
>
> It seems that with 7u25 the result is "shifted"  for one calling 
> frame. Is that behavior change intentional to encourage people to "get 
> off that wagon"?

Right, there is an additional frame that means that getClassClass is out 
by one. This change was unintentional (meaning a bug) and Mandy has a 
fix coming in 7u40 for this, the discussion has been on jdk7u-dev rather 
than here:

http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html

As regards getting people off sun.reflect.Reflection.getCallerClass(int) 
then the proposal is aggressive, you can read the details but it 
essentially means it will be disabled by default in 7u40.

-Alan.



From peter.levart at gmail.com  Tue Jun 25 10:50:55 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 12:50:55 +0200
Subject: @CallerSensitive as public API ?
Message-ID: <51C9760F.7000007@gmail.com>

Hi,

I know that @CallerSensitive annotation was introduced to bring some 
order to JDK internal plumbings. It's scope was to support JDK internal 
usage, so it's use is limited to classes loaded by bootstrap or 
extension class-loaders. In JDK-internal code it is used mainly for 
implementing security-sensitive decisions. But since the 
sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, 
it found it's way out into user code, where at least I know that it is 
used in two areas:

1 - to locate callers in the whole call-stack so that their location in 
class-path can be reported (Log4J is an example)
2 - to locate immediate caller so that some resources associated with it 
can be located and used (for example localization data in GUI applications)

I don't know how wide-spread 1st usecase is, but the 2nd is common, 
since it's use enables APIs that need not explicitly pass-in the calling 
class in order to locate resources associated with it (and/or the 
class-loader of it). So it would be nice to have such supported API in 
JDK8 at least.

I'm asking here, to hear any arguments against making such API supported 
and public. Are there any security or other issues? If there aren't, 
what steps should be taken to introduce such API in the JDK8 timeframe? 
I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving 
@CallerSensitive to a supported package + enabling it to mark methods in 
any class (not just system and ext classes)...

Regards, Peter



From Alan.Bateman at oracle.com  Tue Jun 25 12:25:22 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Jun 2013 13:25:22 +0100
Subject: RFR JDK-8017212 - File.createTempFile requires unnecessary "read"
	permission
In-Reply-To: <51C8E19C.4010205@oracle.com>
References: <51C8E19C.4010205@oracle.com>
Message-ID: <51C98C32.7080109@oracle.com>

On 25/06/2013 01:17, Dan Xu wrote:
> HiAll,
>
> The fix of JDK-8013827 added an unnecessary "read" permission 
> requirement in File.createTempFile methods. This change is going to 
> fix this issue. Please help review it. Thanks!
>
>
> webrev: http://cr.openjdk.java.net/~dxu/8017212/webrev.00/
> bug: http://bugs.sun.com/view_bug.do?bug_id=8017212
This looks fine. Have you considered adding a test? (as it managed to 
slip through with the recent change).

-Alan


From Alan.Bateman at oracle.com  Tue Jun 25 13:03:26 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Jun 2013 14:03:26 +0100
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
Message-ID: <51C9951E.9080104@oracle.com>

On 25/06/2013 00:53, Brian Burkhalter wrote:
> Branching off from this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
>
> I filed this issue (should be public tomorrow)
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
>
> for the getRadixConversionCache() enhancement. The patch is here
>
> http://cr.openjdk.java.net/~bpb/8017540/
>
> I reviewed and tested the code for correctness and see no issues, so to speak. This patch cannot be integrated prior to that for 4641897.
>
I'll push 4641897 for you now and we'll push 8017540 once we are done 
with that review.

-Alan.


From alan.bateman at oracle.com  Tue Jun 25 13:06:09 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 25 Jun 2013 13:06:09 +0000
Subject: hg: jdk8/tl/jdk: 4641897: Faster string conversion of large integers
Message-ID: <20130625130621.89076484E5@hg.openjdk.java.net>

Changeset: 01fcca3d2b8c
Author:    bpb
Date:      2013-06-20 12:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01fcca3d2b8c

4641897: Faster string conversion of large integers
Summary: Accelerate conversion to string by means of Schoenhage recursive base conversion.
Reviewed-by: bpb, alanb
Contributed-by: Alan Eliasen 

! src/share/classes/java/math/BigInteger.java
! test/java/math/BigInteger/BigIntegerTest.java



From alan.bateman at oracle.com  Tue Jun 25 12:55:33 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 25 Jun 2013 12:55:33 +0000
Subject: hg: jdk8/tl/jdk: 8017570: jfr.jar should not be in compact3 (for now)
Message-ID: <20130625125616.7C0AA484E3@hg.openjdk.java.net>

Changeset: 4a4d910e1504
Author:    alanb
Date:      2013-06-25 13:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4d910e1504

8017570: jfr.jar should not be in compact3 (for now)
Reviewed-by: erikj

! makefiles/profile-includes.txt



From weijun.wang at oracle.com  Tue Jun 25 13:51:47 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 25 Jun 2013 13:51:47 +0000
Subject: hg: jdk8/tl/jdk: 8016051: Possible ClassCastException in KdcComm
Message-ID: <20130625135211.865A1484EA@hg.openjdk.java.net>

Changeset: 89631a384ee6
Author:    weijun
Date:      2013-06-25 21:51 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6

8016051: Possible ClassCastException in KdcComm
Reviewed-by: weijun
Contributed-by: Artem Smotrakov 

! src/share/classes/sun/security/krb5/KdcComm.java



From eric.mccorkle at oracle.com  Tue Jun 25 14:03:17 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 25 Jun 2013 10:03:17 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
Message-ID: <51C9A325.4020605@oracle.com>

Hello,

Please review this simple patch which updates regression test
langtools/tools/javac/T6725036.java to offset the time returned by
JavaFileObject.getLastModified() with the local time to UTC delta.

Please note that this patch is intended to address the test failures,
and that I will be immediately opening a new bug to investigate and
address deeper issues, and also to properly document the API.

The webrev is here:
http://cr.openjdk.java.net/~emc/8016760/

The bug report is here:
http://bugs.sun.com/view_bug.do?bug_id=8016760

Thanks,
Eric

From brian.burkhalter at oracle.com  Tue Jun 25 16:07:53 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Jun 2013 09:07:53 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <51C91BCB.70707@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
Message-ID: 


On Jun 24, 2013, at 9:25 PM, Joe Darcy wrote:

>> "Requires the output to be padded with leading zeros to the minimum field width following any sign or radix indicator except when converting NaN or infinity. If the width is not provided, then a MissingFormatWidthException will be thrown."
>> 
>> Comments?
>> 
> 
> As a point of comparison, how does the C specification of printf and how do C implementations handle this combination?

To be certain, which combination precisely do you intend?

Brian

From vicente.romero at oracle.com  Tue Jun 25 15:16:33 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 25 Jun 2013 15:16:33 +0000
Subject: hg: jdk8/tl/langtools: 8017104: javac should have a class for
	primitive types that inherits from Type
Message-ID: <20130625151636.EBE4F484F1@hg.openjdk.java.net>

Changeset: 831467c4c6a7
Author:    vromero
Date:      2013-06-25 16:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/831467c4c6a7

8017104: javac should have a class for primitive types that inherits from Type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/code/Attribute.java
! 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/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeTag.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/model/JavacTypes.java



From Alan.Bateman at oracle.com  Tue Jun 25 16:15:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Jun 2013 17:15:01 +0100
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
Message-ID: <51C9C205.7060808@oracle.com>

On 25/06/2013 00:53, Brian Burkhalter wrote:
> Branching off from this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
>
> I filed this issue (should be public tomorrow)
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
>
> for the getRadixConversionCache() enhancement. The patch is here
>
> http://cr.openjdk.java.net/~bpb/8017540/
>
> I reviewed and tested the code for correctness and see no issues, so to speak.
This looks good.

-Alan


From alexander.zuev at oracle.com  Tue Jun 25 16:09:06 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Tue, 25 Jun 2013 16:09:06 +0000
Subject: hg: jdk8/tl/langtools: 8006973: jtreg test fails:
	test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Message-ID: <20130625160911.C428E484F7@hg.openjdk.java.net>

Changeset: aceae9ceebbe
Author:    kizune
Date:      2013-06-25 20:08 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aceae9ceebbe

8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Reviewed-by: ksrini

! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java



From brian.burkhalter at oracle.com  Tue Jun 25 16:29:19 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Jun 2013 09:29:19 -0700
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9577C.4000301@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
Message-ID: 

Hi Aleksey,

On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:

> Thanks! Looks good to me.

Cool!

> Rather minor silly nit:
> 
>    cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>    for (int i = oldSize; i <= exponent; i++) {
> 
> ...is probably more consistent as:
> 
>    cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>    for (int i = oldSize; i < exponent + 1; i++) {
> 
> This sets up easier subexpression elimination, and also "1" is now
> clearly acts as the "prefetch distance". Although this is the slowpath
> anyway, and does not really matter.

I think we'll just leave it as-is, given that it does not matter.

> -Aleksey.
> (the rural r reviewer)

;-)

Thanks,

Brian

From huizhe.wang at oracle.com  Tue Jun 25 17:10:16 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 25 Jun 2013 10:10:16 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <51C8ECEF.6080200@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8ECEF.6080200@oracle.com>
Message-ID: <51C9CEF8.2080300@oracle.com>

Max,

Can you explain how to use your test library to run a simple test such 
as the one attached with a 3rd party jar on bootclasspath?

e.g.
Proc pc = Proc.create("Test")
           .args("-Xbootclasspath/p:"+pathtoXercesImpljar)
           .start();
is that how 3rd party jar file can be put on the bootclasspath? what else needs to be done after
that in order carry out the test?

Thanks,
Joe

On 6/24/2013 6:05 PM, Weijun Wang wrote:
> On 6/25/13 6:42 AM, Rob McKenna wrote:
>> Some interesting conversations were had lately about shell scripts
>> during Joe Darcy's recent infrastructure tech talk. In particular around
>> the idea of a "jdk.testing" package to provide libraries that would help
>> with the types of operations seen in shell scripts. I'm really hoping to
>> spend some time on this myself over the coming weeks. (in an effort to
>> at least understand why we need shell scripts and whether we could do
>> something else instead)
>
> Oh, I've recently invented a new wheel on loading processes and make 
> them interact with each other
>
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java 
>
>
> An example here
>
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java 
>


>
> --Max
>
>>
>>      -Rob
>>


From xueming.shen at oracle.com  Tue Jun 25 17:50:21 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 25 Jun 2013 10:50:21 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9A325.4020605@oracle.com>
References: <51C9A325.4020605@oracle.com>
Message-ID: <51C9D85D.6080905@oracle.com>

This is fine to be a workaround for the test case for now. It probably will need to be
undo-ed after the propose change for #8015666 get integrated.

http://cr.openjdk.java.net/~sherman/8015666/webrev/

The proposal for #8015666 is to keep the "existing" behavior of ZipEntry.getTime()
to return a LastModifiedTime converted from the zip entry's ms-dos-formatted date/time
field by using the "default" timezone. A new pair ZipEntry.get/setLastModifiedTime()
will be added to access the "real" UTC time stored in the zip entry, if presents.

The API doc will be updated accordingly as well to explicitly explain the source of the
date/time and the its timezone sensitive conversion.

-Sherman

On 06/25/2013 07:03 AM, Eric McCorkle wrote:
> Hello,
>
> Please review this simple patch which updates regression test
> langtools/tools/javac/T6725036.java to offset the time returned by
> JavaFileObject.getLastModified() with the local time to UTC delta.
>
> Please note that this patch is intended to address the test failures,
> and that I will be immediately opening a new bug to investigate and
> address deeper issues, and also to properly document the API.
>
> The webrev is here:
> http://cr.openjdk.java.net/~emc/8016760/
>
> The bug report is here:
> http://bugs.sun.com/view_bug.do?bug_id=8016760
>
> Thanks,
> Eric



From mike.duigou at oracle.com  Tue Jun 25 18:06:45 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 25 Jun 2013 12:06:45 -0600
Subject: RFR (2nd round) 8009736: Comparator API cleanup
In-Reply-To: <51C1EA92.9010102@oracle.com>
References: <51B790E6.6020209@oracle.com> <51BCF8B6.4050307@oracle.com>
	<51C1EA92.9010102@oracle.com>
Message-ID: <3A510BB7-1F00-49BE-8AD6-DBAEA38B76A6@oracle.com>

Looks good. Only a few minor nits.

A few places (BiOperator) where it says "Constructs" rather than "Returns". If it is important that it constructs a new instance for consistency you may wish to say "Returns a new ..."

There are a few places of incorrect capitalization in @return and @param tags

Mike

On Jun 19 2013, at 11:29 , Henry Jen wrote:

> A ping to wake up the thread, there is a minor update regard the use of
> @apiNote since last email.
> 
> Thanks in advance for reviewing.
> 
> Cheers,
> Henry
> 
> 
> On 06/15/2013 04:28 PM, Henry Jen wrote:
>> Reflecting feedbacks received so far, please see
>> 
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/webrev/
>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.3/specdiff
>> 
>> Cheers,
>> Henry
>> 
>> 
>> On 06/11/2013 02:04 PM, Henry Jen wrote:
>>> Hi,
>>> 
>>> Please review http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/webrev/
>>> 
>>> Highlight of changes,
>>> 
>>> - Comparators class is now only package-private implementations. The
>>> public static methods have been move to other arguably more appropriate
>>> places, mostly in Comparator.
>>> 
>>> - Comparator.reverseOrder() is renamed to Comparator.reversed()
>>> 
>>> - nullsFirst(Comparator) and nullsLast(Comparator) are introduced to
>>> wrap up a comparator to be null-friendly.
>>> 
>>> To see the API changes, found the specdiff at
>>> http://cr.openjdk.java.net/~henryjen/ccc/8009736.2/specdiff/overview-summary.html
>>> 
>>> Cheers,
>>> Henry
>>> 
>> 
> 



From peter.levart at gmail.com  Tue Jun 25 18:13:47 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 20:13:47 +0200
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C58262.6030403@oracle.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
Message-ID: <51C9DDDB.5080800@gmail.com>


On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
>    T get(int index1, index2) {
>       T[][] lc = cache;
>       if (index1 >= lc.length) { // needs resizing
>          lc = ((index1 << 1) + 1);
>          cache = lc;
>       }
>       T[] lt = lc[*index2*];
>       if (index2 >= lt.length) { // needs resizing
>          lt = ((index2 << 1) + 1);
>          lc[index1] = lt;
>          cache = lc; // publish
>       }
>       return lt[index2];
>    }
>
> -Aleksey.

Hi Aleksey,

1st I think there's a typo in above bolded part. There should be index1 
instead of index2 there, right?

Then I think there's a data race in above code which can de-reference 
half-constructed array and an element within it:

tread A:

T[][] lc = cache;
     // skip 1st if, since index1 < lc.length

thread B:

     T[][] lc = cache;
     // skip 1st if, since index1 < lc.length
     T[] lt = lc[index1];
     // enter 2nd if, since index2 >= lt.length;
     lt = ((index2 << 1) + 1);
     lc[index1] = lt;

thread A:
     T[] lt = lc[index1]; // this reads a reference to new lt array, 
written by thread B (data-race)
     // skip 2nd if, since index2 < lt.length
     return lt[index2];   // this could read and return null, since 
array reference was obtained via data-race


I have studied the constraints of powerCache and have observed:

- the capacity/size of 1st level is constant and doesn't need resizing 
(37 slots, since Character.MAX_RADIX == 36)
- the virtual "length" field of each array is "final", meaning that at 
least length of the array can be obtained safely although the reference 
to the array was obtained via data-race
- the BigInteger class is effectively final (the meaningful state is 
held via final fields and non-final fields are just caches of some info 
which can be re-computed idempotently - like String.hash), meaning that 
a reference to BigInteger can be obtained via data-race and still the 
object will behave consistently.

So the caching could be performed with no synchronization (other than 
that provided by final fields descibed above).

Here is a possible variant of such caching:


     private static final BigInteger[][] powerCache =
         new BigInteger[Character.MAX_RADIX + 1][];

     private static BigInteger getRadixConversionCache(
         int radix,
         int exponent
     ) {
         BigInteger[] cacheLine = powerCache[radix];
         int oldLength = cacheLine == null ? 0 : cacheLine.length;
         if (exponent >= oldLength) { // needs resizing/creation?
             // invariant: each cacheLine has length > 0
             if (oldLength == 0) { // creation
                 cacheLine = new BigInteger[exponent + 1];
             }
             else { // resizing
                 // increase by factor of 1.5 (like ArrayList)
                 int newLength = oldLength + (oldLength >> 1);
                 // if that's not enough, take exact needed length
                 if (newLength <= exponent) newLength = exponent + 1;
                 cacheLine = Arrays.copyOf(cacheLine, newLength);
             }
             powerCache[radix] = cacheLine; // install new cacheLine
         }
         // search for 1st non-null power from min(oldLength - 1, 
exponent) backwards
         int s;
         BigInteger power = null;
         for (s = Math.min(oldLength - 1, exponent); s >= 0; s--) {
             power = cacheLine[s];
             if (power != null) break;
         }
         // calculate the rest up to and including exponent
         for (int i = s + 1; i <= exponent; i++) {
             power = power == null ? BigInteger.valueOf(radix) : 
power.square();
             cacheLine[i] = power;
         }
         return power;
     }



Please, be free to find a fault in this code ;-)

Regards, Peter



From mike.duigou at oracle.com  Tue Jun 25 18:15:37 2013
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 25 Jun 2013 12:15:37 -0600
Subject: RFR : 8013712 : (XS) Add Objects.nonNull and Objects.isNull
In-Reply-To: <51C2FF51.3060802@univ-mlv.fr>
References: 
	
	<51C2FF51.3060802@univ-mlv.fr>
Message-ID: 

I am sympathetic to this naming issue (actually "indifferent" is more accurate) but it will have to wait until I return from vacation. I have tagged this thread and will follow up when I am back in the office. Please be patient, it will be addressed.

Mike

On Jun 20 2013, at 07:10 , Remi Forax wrote:

> Yes, a fine idea.
> 
> R?mi
> 
> On 06/20/2013 11:44 AM, Stephen Colebourne wrote:
>> Like others, I would prefer isNotNull() to notNull(). Mainly for
>> consistency, but also for dicoverability is IDE autocomplete (as the
>> methods would then be next to one another)
>> Stephen
>> 
>> 
>> On 30 April 2013 23:45, Mike Duigou  wrote:
>>> Hello all;
>>> 
>>> Another changeset coming from the lambda libraries effort. This one is two small additions to the Objects class. The introduced methods are not really intended to be used directly, comparison operators work better in imperative logic, but the methods will be very useful as Predicates.
>>> 
>>> http://cr.openjdk.java.net/~mduigou/JDK-8013712/0/webrev/
>>> 
>>> Thanks,
>>> 
>>> Mike
> 



From eric.mccorkle at oracle.com  Tue Jun 25 18:33:15 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 25 Jun 2013 14:33:15 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9D85D.6080905@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
Message-ID: <51C9E26B.3070000@oracle.com>

Is this a capital-R review?

On 06/25/13 13:50, Xueming Shen wrote:
> This is fine to be a workaround for the test case for now. It probably
> will need to be
> undo-ed after the propose change for #8015666 get integrated.
> 
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
> 
> The proposal for #8015666 is to keep the "existing" behavior of
> ZipEntry.getTime()
> to return a LastModifiedTime converted from the zip entry's
> ms-dos-formatted date/time
> field by using the "default" timezone. A new pair
> ZipEntry.get/setLastModifiedTime()
> will be added to access the "real" UTC time stored in the zip entry, if
> presents.
> 
> The API doc will be updated accordingly as well to explicitly explain
> the source of the
> date/time and the its timezone sensitive conversion.
> 
> -Sherman
> 
> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>> Hello,
>>
>> Please review this simple patch which updates regression test
>> langtools/tools/javac/T6725036.java to offset the time returned by
>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>
>> Please note that this patch is intended to address the test failures,
>> and that I will be immediately opening a new bug to investigate and
>> address deeper issues, and also to properly document the API.
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8016760/
>>
>> The bug report is here:
>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>
>> Thanks,
>> Eric
> 

From aleksey.shipilev at oracle.com  Tue Jun 25 18:45:43 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 22:45:43 +0400
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C9DDDB.5080800@gmail.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
	<51C9DDDB.5080800@gmail.com>
Message-ID: <51C9E557.1070208@oracle.com>

On 06/25/2013 10:13 PM, Peter Levart wrote:
> 
> On 06/22/2013 12:54 PM, Aleksey Shipilev wrote:
>>   T get(int index1, index2) {
>>      T[][] lc = cache;
>>      if (index1 >= lc.length) { // needs resizing
>>         lc = ((index1 << 1) + 1);
>>         cache = lc;
>>      }
>>      T[] lt = lc[*index2*];
>>      if (index2 >= lt.length) { // needs resizing
>>         lt = ((index2 << 1) + 1);
>>         lc[index1] = lt;
>>         cache = lc; // publish
>>      }
>>      return lt[index2];
>>   }
>>
>> -Aleksey.
> 
> Hi Aleksey,
> 
> 1st I think there's a typo in above bolded part. There should be index1
> instead of index2 there, right?

Nope, lc is indexed with index2; lt is indexed with index1.

> Then I think there's a data race in above code which can de-reference
> half-constructed array and an element within it:

Damn. Good point, let's discuss that in the appropriate RFR, see 8017540.

> I have studied the constraints of powerCache and have observed:

> So the caching could be performed with no synchronization (other than
> that provided by final fields descibed above).

Yeah, we can do that with finals. Too bad you can't have the final
semantics with BigInteger[] array.

> Here is a possible variant of such caching:

Seems overcomplicated. ;) Let's instead fix the code proposed in 8017540.

Thanks,
Aleksey.


From xueming.shen at oracle.com  Tue Jun 25 18:47:50 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 25 Jun 2013 11:47:50 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9E26B.3070000@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9E26B.3070000@oracle.com>
Message-ID: <51C9E5D6.2020704@oracle.com>


It is intended to be an opinion. I would assume you would like a reviewer from
the langtool team to push the change, given the changset is for the lang repo.

You may want to update the "check()" method as well to low the granularity
to 2-second before comparing the equality. The timestamp from the ms-dos
formatted date/time has 2-second granularity, but the new one has second
granularity, so the test case may still fail in some odd timing.

-Sherman

On 06/25/2013 11:33 AM, Eric McCorkle wrote:
> Is this a capital-R review?
>
> On 06/25/13 13:50, Xueming Shen wrote:
>> This is fine to be a workaround for the test case for now. It probably
>> will need to be
>> undo-ed after the propose change for #8015666 get integrated.
>>
>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>
>> The proposal for #8015666 is to keep the "existing" behavior of
>> ZipEntry.getTime()
>> to return a LastModifiedTime converted from the zip entry's
>> ms-dos-formatted date/time
>> field by using the "default" timezone. A new pair
>> ZipEntry.get/setLastModifiedTime()
>> will be added to access the "real" UTC time stored in the zip entry, if
>> presents.
>>
>> The API doc will be updated accordingly as well to explicitly explain
>> the source of the
>> date/time and the its timezone sensitive conversion.
>>
>> -Sherman
>>
>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this simple patch which updates regression test
>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>
>>> Please note that this patch is intended to address the test failures,
>>> and that I will be immediately opening a new bug to investigate and
>>> address deeper issues, and also to properly document the API.
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8016760/
>>>
>>> The bug report is here:
>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>
>>> Thanks,
>>> Eric



From mandy.chung at oracle.com  Tue Jun 25 18:53:14 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 25 Jun 2013 11:53:14 -0700
Subject: @CallerSensitive in Java SE 7u25
In-Reply-To: <51C96FC2.2040200@oracle.com>
References: <51C96B9C.3070305@gmail.com> <51C96FC2.2040200@oracle.com>
Message-ID: <51C9E71A.2010004@oracle.com>

On 6/25/13 3:24 AM, Alan Bateman wrote:
> On 25/06/2013 11:06, Peter Levart wrote:
>> :
>>
>> It seems that with 7u25 the result is "shifted"  for one calling 
>> frame. Is that behavior change intentional to encourage people to 
>> "get off that wagon"?
>
> Right, there is an additional frame that means that getClassClass is 
> out by one. This change was unintentional (meaning a bug) and Mandy 
> has a fix coming in 7u40 for this, the discussion has been on 
> jdk7u-dev rather than here:
>
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-June/006791.html
>

The changeset will be pushed to jdk7u40-dev repo as soon as it's open 
for business.   The regression was unintentional and it was unforunate 
that the test didn't catch it as it happened two frames have the same 
caller class (my apology).

Mandy

> As regards getting people off 
> sun.reflect.Reflection.getCallerClass(int) then the proposal is 
> aggressive, you can read the details but it essentially means it will 
> be disabled by default in 7u40.
>
> -Alan.
>



From chris.hegarty at oracle.com  Tue Jun 25 19:07:56 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 25 Jun 2013 19:07:56 +0000
Subject: hg: jdk8/tl/jdk: 8014233: java.lang.Thread should have @Contended on
	TLR fields
Message-ID: <20130625190820.3D28D484FE@hg.openjdk.java.net>

Changeset: ac61efd8c593
Author:    shade
Date:      2013-06-25 20:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac61efd8c593

8014233: java.lang.Thread should have @Contended on TLR fields
Summary: add the @Contended over three TLR fields.
Reviewed-by: psandoz, chegar, dholmes, dl

! src/share/classes/java/lang/Thread.java



From eliasen at mindspring.com  Tue Jun 25 19:09:42 2013
From: eliasen at mindspring.com (Alan Eliasen)
Date: Tue, 25 Jun 2013 13:09:42 -0600
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C9DDDB.5080800@gmail.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
	<51C9DDDB.5080800@gmail.com>
Message-ID: <51C9EAF6.40201@mindspring.com>

On 06/25/2013 12:13 PM, Peter Levart wrote:
>             else { // resizing
>                 // increase by factor of 1.5 (like ArrayList)
>                 int newLength = oldLength + (oldLength >> 1);

   We probably don't ever want to extend any row of this cache any more
than we need to.  The entries in each row of the cache, say for base 10,
are 10^(2^n) which obviously grows super-exponentially with n.  (And the
time to perform each squaring to get successive terms will grow
quadratically or at least subquadratically on top of that, along with
memory usage which squares with each additional term.)  So we should
never resize to more entries in that table than we need, and we should
try to avoid recalculating entries in that table in multiple threads, as
the cost to calculate them can be high.

   As I noted years ago, the caching behavior is certainly going to be
one of the most controversial parts of BigInteger improvements.  :)

-- 
  Alan Eliasen
  eliasen at mindspring.com
  http://futureboy.us/


From aleksey.shipilev at oracle.com  Tue Jun 25 19:12:37 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 23:12:37 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
	<51C9577C.4000301@oracle.com>
	
Message-ID: <51C9EBA5.4020002@oracle.com>

On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
> Hi Aleksey,
> 
> On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
> 
>> Thanks! Looks good to me.
> 
> Cool!

Hold on now. Similar to what Peter suggests in the separate thread,
there is the data race between 3458 and 3466:

3455     private static BigInteger getRadixConversionCache(int radix,
int exponent) {

3456         BigInteger retVal = null;
3457         BigInteger[][] pc = powerCache; // volatile read
3458         BigInteger[] cacheLine = pc[radix];
3459         int oldSize = cacheLine.length;
3460         if (exponent >= oldSize) {
3461             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
3462             for (int i = oldSize; i <= exponent; i++) {
3463                 retVal = cacheLine[i - 1].square();
3464                 cacheLine[i] = retVal;
3465             }
3466             pc[radix] = cacheLine;
3467             powerCache = pc; // publish by volatile write
3468         } else {
3469             retVal = cacheLine[exponent];
3470         }

The observable behavior in one of the threads:
 a) reading cacheLine in 3458
 b) figuring the cacheLine.length is N
 c) querying cacheLine[N-1]
 d) since new cacheLine is published via data race, can see
    (cacheLine[N-1] == null)
 e) boom! NPE in caller.

That's the only trouble I see. BigInteger is effectively final and
publishable by data race. array.length is good even when published via
data race. Note that this particular trouble have no chance to manifest
itself on x86 (modulo some runtime optimizations), because the stores
are ordered there.

Unfortunately, solving this "cleanly" requires the final-like semantics
for $cacheLine, which lends itself into creating the wrapper around
BigInteger[]. It seems simpler to fallback and recover while the data
race resolves, e.g.:

private static volatile BigInteger[][] powerCache;

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger retVal = null;
  BigInteger[][] pc = powerCache; // volatile read
  BigInteger[] cacheLine = pc[radix];
  int oldSize = cacheLine.length;
  if (exponent >= oldSize) {
      cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
      for (int i = oldSize; i <= exponent; i++) {
          retVal = cacheLine[i - 1].square();
          cacheLine[i] = retVal;
      }
      pc[radix] = cacheLine;
      powerCache = pc; // volatile write, publish
  } else {
      retVal = cacheLine[exponent];
      if (retVal == null) {
          // data race, element is not available yet,
          // compute on the fly
          retVal = BigInteger.valueOf(radix);
          for (int c = 0; c < exponent; c++) {
              retVal = retVal.square();
          }
      }
  }
  return retVal;
}

(In retrospect, this seems the variation on Peter's idea, but fallback
code is much simpler)

It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway. The trouble I'm seeing is weak enough
hardware, which will never see the updated value of cacheLine, always
falling back. Hence, I'm keen to keep "volatile".

I haven't tested this code, so...

-Aleksey.


From mandy.chung at oracle.com  Tue Jun 25 19:24:11 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 25 Jun 2013 12:24:11 -0700
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9760F.7000007@gmail.com>
References: <51C9760F.7000007@gmail.com>
Message-ID: <51C9EE5B.8050300@oracle.com>

On 6/25/13 3:50 AM, Peter Levart wrote:
> Hi,
>
> I know that @CallerSensitive annotation was introduced to bring some 
> order to JDK internal plumbings. It's scope was to support JDK 
> internal usage, so it's use is limited to classes loaded by bootstrap 
> or extension class-loaders. In JDK-internal code it is used mainly for 
> implementing security-sensitive decisions. But since the 
> sun.reflect.Reflection.getCallerClass(int) was public and 
> unrestricted, it found it's way out into user code, where at least I 
> know that it is used in two areas:
>
> 1 - to locate callers in the whole call-stack so that their location 
> in class-path can be reported (Log4J is an example)
> 2 - to locate immediate caller so that some resources associated with 
> it can be located and used (for example localization data in GUI 
> applications)
>
> I don't know how wide-spread 1st usecase is, but the 2nd is common, 
> since it's use enables APIs that need not explicitly pass-in the 
> calling class in order to locate resources associated with it (and/or 
> the class-loader of it). So it would be nice to have such supported 
> API in JDK8 at least.
>

It's good to know these use cases.  We leave the method in 7 update 
release so as to allow time for applications to transition and also 
determine any use case that the SE API should provide if there is no 
replacement for it.

> I'm asking here, to hear any arguments against making such API 
> supported and public. Are there any security or other issues? If there 
> aren't, what steps should be taken to introduce such API in the JDK8 
> timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() 
> and moving @CallerSensitive to a supported package + enabling it to 
> mark methods in any class (not just system and ext classes)...

Besides providing a method returning the caller's class, I'd like to 
consider what other options we have and different use cases could be 
satisfied by different API.  For #2, the problem is that the API to find 
a resource, it requires to use the ClassLoader with the right visibility 
(the caller's class loader).  This is similiar to 8013839 : Enhance 
Logger API for handling of resource bundles [1]. For example, a static 
method Class.getResource to use the caller's class loader to find the 
given resource might be an alternative?

About the timeframe, the API freeze date [2] is Oct 10.  If the API is 
simple and small effort (test development, security assessement, etc), 
there is chance to get that in for jdk8.

Mandy
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
[2] http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze



From eric.mccorkle at oracle.com  Tue Jun 25 19:27:01 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 25 Jun 2013 15:27:01 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9D85D.6080905@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
Message-ID: <51C9EF05.8000803@oracle.com>

Does the fix for 8015666 stop the error from happening?  If so, then
I'll withdraw this RFR.

On 06/25/13 13:50, Xueming Shen wrote:
> This is fine to be a workaround for the test case for now. It probably
> will need to be
> undo-ed after the propose change for #8015666 get integrated.
> 
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
> 
> The proposal for #8015666 is to keep the "existing" behavior of
> ZipEntry.getTime()
> to return a LastModifiedTime converted from the zip entry's
> ms-dos-formatted date/time
> field by using the "default" timezone. A new pair
> ZipEntry.get/setLastModifiedTime()
> will be added to access the "real" UTC time stored in the zip entry, if
> presents.
> 
> The API doc will be updated accordingly as well to explicitly explain
> the source of the
> date/time and the its timezone sensitive conversion.
> 
> -Sherman
> 
> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>> Hello,
>>
>> Please review this simple patch which updates regression test
>> langtools/tools/javac/T6725036.java to offset the time returned by
>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>
>> Please note that this patch is intended to address the test failures,
>> and that I will be immediately opening a new bug to investigate and
>> address deeper issues, and also to properly document the API.
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8016760/
>>
>> The bug report is here:
>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>
>> Thanks,
>> Eric
> 

From peter.levart at gmail.com  Tue Jun 25 19:33:20 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 21:33:20 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
Message-ID: <51C9F080.1080105@gmail.com>


On 06/25/2013 01:53 AM, Brian Burkhalter wrote:
> Branching off from this thread
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018244.html
>
> I filed this issue (should be public tomorrow)
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540
>
> for the getRadixConversionCache() enhancement. The patch is here
>
> http://cr.openjdk.java.net/~bpb/8017540/
>
> I reviewed and tested the code for correctness and see no issues, so to speak. This patch cannot be integrated prior to that for 4641897.
>
> Thanks,
>
> Brian

Hi,

I think this has similar problem (data-race followed by read from 
half-constructed array) as the prototype that Aleksey constructed here 
(sorry, I have not seen the forked thread then yet):

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018368.html


     private static BigInteger getRadixConversionCache(int radix, int exponent) {
         BigInteger retVal = null;
         BigInteger[][] pc = powerCache; // volatile read
         BigInteger[] cacheLine = pc[radix];
         int oldSize = cacheLine.length;
         if (exponent >= oldSize) {
             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
             for (int i = oldSize; i <= exponent; i++) {
                 retVal = cacheLine[i - 1].square();
                 cacheLine[i] = retVal;
             }
             pc[radix] = cacheLine;
             powerCache = pc; // publish by volatile write
         } else {
             retVal = cacheLine[exponent];
         }

         return retVal;
      }



Thread A:
     pc = powerCache;

Thread B:
     pc = powerCache;
     cacheLine = pc[radix];
     oldSize = cacheLine.length;
     // enter if, since exponent >= oldSize
     cacheLine = copyOf(cacheLine, exponent+1);
     // ...for loop filling cacheLine...
     pc[radix] = cacheLine;

Thread A:
     cacheLine = pc[radix]; // this can read new cache line constructed 
by Thread B (data-race)
     oldSize = cacheLine.length;
     // skip if, since exponent < oldSize, enter else
     retVal = cacheLine[exponent]; // this can read null, since 
reference to cacheLine was obtained via data-race
     return retval;


What do you think of the code proposed here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018368.html


Regards, Peter



From dmitry.nadezhin at gmail.com  Tue Jun 25 19:36:54 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Tue, 25 Jun 2013 23:36:54 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9EBA5.4020002@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
Message-ID: 

What about such code ?

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger retVal = null;
  BigInteger[][] pc = powerCache; // volatile read
  BigInteger[] cacheLine = pc[radix];
  int oldSize = cacheLine.length;
  if (exponent >= oldSize) {
      cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
      for (int i = oldSize; i <= exponent; i++) {
          retVal = cacheLine[i - 1].square();
          cacheLine[i] = retVal;
      }
      synchronized (pc) {
        if (pc[radix].length < cacheLine.length) {
          pc[radix] = cacheLine;
          powerCache = pc; // volatile write, publish
        }
      }
  } else {
      retVal = cacheLine[exponent];
  }
  return retVal;
}

Is dummy volatile write necessary inside synchronized block ?
          powerCache = pc; // volatile write, publish


On Tue, Jun 25, 2013 at 11:12 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
> > Hi Aleksey,
> >
> > On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
> >
> >> Thanks! Looks good to me.
> >
> > Cool!
>
> Hold on now. Similar to what Peter suggests in the separate thread,
> there is the data race between 3458 and 3466:
>
> 3455     private static BigInteger getRadixConversionCache(int radix,
> int exponent) {
>
> 3456         BigInteger retVal = null;
> 3457         BigInteger[][] pc = powerCache; // volatile read
> 3458         BigInteger[] cacheLine = pc[radix];
> 3459         int oldSize = cacheLine.length;
> 3460         if (exponent >= oldSize) {
> 3461             cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
> 3462             for (int i = oldSize; i <= exponent; i++) {
> 3463                 retVal = cacheLine[i - 1].square();
> 3464                 cacheLine[i] = retVal;
> 3465             }
> 3466             pc[radix] = cacheLine;
> 3467             powerCache = pc; // publish by volatile write
> 3468         } else {
> 3469             retVal = cacheLine[exponent];
> 3470         }
>
> The observable behavior in one of the threads:
>  a) reading cacheLine in 3458
>  b) figuring the cacheLine.length is N
>  c) querying cacheLine[N-1]
>  d) since new cacheLine is published via data race, can see
>     (cacheLine[N-1] == null)
>  e) boom! NPE in caller.
>
> That's the only trouble I see. BigInteger is effectively final and
> publishable by data race. array.length is good even when published via
> data race. Note that this particular trouble have no chance to manifest
> itself on x86 (modulo some runtime optimizations), because the stores
> are ordered there.
>
> Unfortunately, solving this "cleanly" requires the final-like semantics
> for $cacheLine, which lends itself into creating the wrapper around
> BigInteger[]. It seems simpler to fallback and recover while the data
> race resolves, e.g.:
>
> private static volatile BigInteger[][] powerCache;
>
> BigInteger getRadixConversionCache(int radix, int exponent) {
>   BigInteger retVal = null;
>   BigInteger[][] pc = powerCache; // volatile read
>   BigInteger[] cacheLine = pc[radix];
>   int oldSize = cacheLine.length;
>   if (exponent >= oldSize) {
>       cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>       for (int i = oldSize; i <= exponent; i++) {
>           retVal = cacheLine[i - 1].square();
>           cacheLine[i] = retVal;
>       }
>       pc[radix] = cacheLine;
>       powerCache = pc; // volatile write, publish
>   } else {
>       retVal = cacheLine[exponent];
>       if (retVal == null) {
>           // data race, element is not available yet,
>           // compute on the fly
>           retVal = BigInteger.valueOf(radix);
>           for (int c = 0; c < exponent; c++) {
>               retVal = retVal.square();
>           }
>       }
>   }
>   return retVal;
> }
>
> (In retrospect, this seems the variation on Peter's idea, but fallback
> code is much simpler)
>
> It might be a good idea to turn $powerCache final, not volatile, since
> the code will recover anyway. The trouble I'm seeing is weak enough
> hardware, which will never see the updated value of cacheLine, always
> falling back. Hence, I'm keen to keep "volatile".
>
> I haven't tested this code, so...
>
> -Aleksey.
>


From peter.levart at gmail.com  Tue Jun 25 19:38:04 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 21:38:04 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9EBA5.4020002@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
Message-ID: <51C9F19C.5080103@gmail.com>


On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
> It might be a good idea to turn $powerCache final, not volatile, since
> the code will recover anyway. The trouble I'm seeing is weak enough
> hardware, which will never see the updated value of cacheLine, always
> falling back. Hence, I'm keen to keep "volatile".

The worst thing that could happen is that each thread would effectively 
have it's private cache.

Regards, Peter



From xueming.shen at oracle.com  Tue Jun 25 19:45:18 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 25 Jun 2013 12:45:18 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9EF05.8000803@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9EF05.8000803@oracle.com>
Message-ID: <51C9F34E.9000403@oracle.com>

The proposed change for 8015666 is supposed to stop this test failure. But as I said
last time that it may take a while for it to get into the repo. I will start the CCC process
shortly, if there is no objection.

-Sherman

On 06/25/2013 12:27 PM, Eric McCorkle wrote:
> Does the fix for 8015666 stop the error from happening?  If so, then
> I'll withdraw this RFR.
>
> On 06/25/13 13:50, Xueming Shen wrote:
>> This is fine to be a workaround for the test case for now. It probably
>> will need to be
>> undo-ed after the propose change for #8015666 get integrated.
>>
>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>
>> The proposal for #8015666 is to keep the "existing" behavior of
>> ZipEntry.getTime()
>> to return a LastModifiedTime converted from the zip entry's
>> ms-dos-formatted date/time
>> field by using the "default" timezone. A new pair
>> ZipEntry.get/setLastModifiedTime()
>> will be added to access the "real" UTC time stored in the zip entry, if
>> presents.
>>
>> The API doc will be updated accordingly as well to explicitly explain
>> the source of the
>> date/time and the its timezone sensitive conversion.
>>
>> -Sherman
>>
>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this simple patch which updates regression test
>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>
>>> Please note that this patch is intended to address the test failures,
>>> and that I will be immediately opening a new bug to investigate and
>>> address deeper issues, and also to properly document the API.
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8016760/
>>>
>>> The bug report is here:
>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>
>>> Thanks,
>>> Eric



From aleksey.shipilev at oracle.com  Tue Jun 25 19:50:03 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 23:50:03 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9F19C.5080103@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
Message-ID: <51C9F46B.4010701@oracle.com>

On 06/25/2013 11:38 PM, Peter Levart wrote:
> 
> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
>> It might be a good idea to turn $powerCache final, not volatile, since
>> the code will recover anyway. The trouble I'm seeing is weak enough
>> hardware, which will never see the updated value of cacheLine, always
>> falling back. Hence, I'm keen to keep "volatile".
> 
> The worst thing that could happen is that each thread would effectively
> have it's private cache.

Right.

That only works if you store the fallback value to cacheLine, and then
back to powerCache, since the second get...() will possibly re-read the
stale cacheLine otherwise. Your version did that. Do we want to store
the retVal?

private static final BigInteger[][] powerCache;

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger retVal = null;
  BigInteger[][] pc = powerCache;
  BigInteger[] cacheLine = pc[radix];
  int oldSize = cacheLine.length;
  if (exponent >= oldSize) {
      cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
      for (int i = oldSize; i <= exponent; i++) {
          retVal = cacheLine[i - 1].square();
          cacheLine[i] = retVal;
      }
      pc[radix] = cacheLine;
  } else {
      retVal = cacheLine[exponent];
      if (retVal == null) {
          // data race, element is not available yet,
          // compute on the fly
          retVal = BigInteger.valueOf(radix);
          for (int c = 0; c < exponent; c++) {
              retVal = retVal.square();
          }
          cacheLine[exponent] = retVal;
      }
  }

-Aleksey.



From aleksey.shipilev at oracle.com  Tue Jun 25 19:53:27 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 25 Jun 2013 23:53:27 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
Message-ID: <51C9F537.1050002@oracle.com>

On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
> What about such code ?
> 
> BigInteger getRadixConversionCache(int radix, int exponent) {
>   BigInteger retVal = null;
>   BigInteger[][] pc = powerCache; // volatile read
>   BigInteger[] cacheLine = pc[radix];
>   int oldSize = cacheLine.length;
>   if (exponent >= oldSize) {
>       cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>       for (int i = oldSize; i <= exponent; i++) {
>           retVal = cacheLine[i - 1].square();
>           cacheLine[i] = retVal;
>       }
>       synchronized (pc) {
>         if (pc[radix].length < cacheLine.length) {
>           pc[radix] = cacheLine;
>           powerCache = pc; // volatile write, publish
>         }
>       }
>   } else {
>       retVal = cacheLine[exponent];
>   }
>   return retVal;
> }

Still the same race. The reader thread sees the full-length cacheLine
early, but the elements are not yet there.

> Is dummy volatile write necessary inside synchronized block ?
>           powerCache = pc; // volatile write, publish
> 

Yes, since you need to have the matched synchronized(pc) otherwise to
produce the pairwise "acquire".

-Aleksey.



From peter.levart at gmail.com  Tue Jun 25 19:56:06 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 21:56:06 +0200
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9EE5B.8050300@oracle.com>
References: <51C9760F.7000007@gmail.com> <51C9EE5B.8050300@oracle.com>
Message-ID: <51C9F5D6.2090207@gmail.com>


On 06/25/2013 09:24 PM, Mandy Chung wrote:
>> I'm asking here, to hear any arguments against making such API 
>> supported and public. Are there any security or other issues? If 
>> there aren't, what steps should be taken to introduce such API in the 
>> JDK8 timeframe? I'm thinking of a no-arg method, say 
>> j.l.Class.getCaller() and moving @CallerSensitive to a supported 
>> package + enabling it to mark methods in any class (not just system 
>> and ext classes)...
>
> Besides providing a method returning the caller's class, I'd like to 
> consider what other options we have and different use cases could be 
> satisfied by different API.  For #2, the problem is that the API to 
> find a resource, it requires to use the ClassLoader with the right 
> visibility (the caller's class loader).  This is similiar to 8013839 : 
> Enhance Logger API for handling of resource bundles [1].  For example, 
> a static method Class.getResource to use the caller's class loader to 
> find the given resource might be an alternative?

Might be enough sometimes, but usually the ClassLoader is not enough, 
since the location of resources (resource path) might be determined by 
caller's class name or package (relative to caller's class, for 
example). So perhaps, if j.l.Class object is to security sensitive, a 
tuple (caller ClassLoader, caller class name) might be enough for #2 usages.

Regards, Peter



From chris.hegarty at oracle.com  Tue Jun 25 19:56:48 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 25 Jun 2013 20:56:48 +0100
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9F34E.9000403@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9EF05.8000803@oracle.com> <51C9F34E.9000403@oracle.com>
Message-ID: <51C9F600.4020700@oracle.com>

On 06/25/2013 08:45 PM, Xueming Shen wrote:
> The proposed change for 8015666 is supposed to stop this test failure.
> But as I said
> last time that it may take a while for it to get into the repo. I will
> start the CCC process
> shortly, if there is no objection.

There is no problem here. If 8015666 will resolve the test failure, then 
we can simply use 8016760 to add the test to the ProblemList.txt. It can 
then be removed along with the other changes for 8015666.

-Chris.


>
> -Sherman
>
> On 06/25/2013 12:27 PM, Eric McCorkle wrote:
>> Does the fix for 8015666 stop the error from happening?  If so, then
>> I'll withdraw this RFR.
>>
>> On 06/25/13 13:50, Xueming Shen wrote:
>>> This is fine to be a workaround for the test case for now. It probably
>>> will need to be
>>> undo-ed after the propose change for #8015666 get integrated.
>>>
>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>
>>> The proposal for #8015666 is to keep the "existing" behavior of
>>> ZipEntry.getTime()
>>> to return a LastModifiedTime converted from the zip entry's
>>> ms-dos-formatted date/time
>>> field by using the "default" timezone. A new pair
>>> ZipEntry.get/setLastModifiedTime()
>>> will be added to access the "real" UTC time stored in the zip entry, if
>>> presents.
>>>
>>> The API doc will be updated accordingly as well to explicitly explain
>>> the source of the
>>> date/time and the its timezone sensitive conversion.
>>>
>>> -Sherman
>>>
>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>> Hello,
>>>>
>>>> Please review this simple patch which updates regression test
>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>
>>>> Please note that this patch is intended to address the test failures,
>>>> and that I will be immediately opening a new bug to investigate and
>>>> address deeper issues, and also to properly document the API.
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>
>>>> The bug report is here:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>
>>>> Thanks,
>>>> Eric
>


From eric.mccorkle at oracle.com  Tue Jun 25 20:21:30 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Tue, 25 Jun 2013 16:21:30 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9F34E.9000403@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9EF05.8000803@oracle.com> <51C9F34E.9000403@oracle.com>
Message-ID: <51C9FBCA.7030608@oracle.com>

Please do; this test has been failing for almost a month now.

On 06/25/13 15:45, Xueming Shen wrote:
> The proposed change for 8015666 is supposed to stop this test failure.
> But as I said
> last time that it may take a while for it to get into the repo. I will
> start the CCC process
> shortly, if there is no objection.
> 
> -Sherman
> 
> On 06/25/2013 12:27 PM, Eric McCorkle wrote:
>> Does the fix for 8015666 stop the error from happening?  If so, then
>> I'll withdraw this RFR.
>>
>> On 06/25/13 13:50, Xueming Shen wrote:
>>> This is fine to be a workaround for the test case for now. It probably
>>> will need to be
>>> undo-ed after the propose change for #8015666 get integrated.
>>>
>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>
>>> The proposal for #8015666 is to keep the "existing" behavior of
>>> ZipEntry.getTime()
>>> to return a LastModifiedTime converted from the zip entry's
>>> ms-dos-formatted date/time
>>> field by using the "default" timezone. A new pair
>>> ZipEntry.get/setLastModifiedTime()
>>> will be added to access the "real" UTC time stored in the zip entry, if
>>> presents.
>>>
>>> The API doc will be updated accordingly as well to explicitly explain
>>> the source of the
>>> date/time and the its timezone sensitive conversion.
>>>
>>> -Sherman
>>>
>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>> Hello,
>>>>
>>>> Please review this simple patch which updates regression test
>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>
>>>> Please note that this patch is intended to address the test failures,
>>>> and that I will be immediately opening a new bug to investigate and
>>>> address deeper issues, and also to properly document the API.
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>
>>>> The bug report is here:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>
>>>> Thanks,
>>>> Eric
> 

From peter.levart at gmail.com  Tue Jun 25 20:34:09 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 22:34:09 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9F46B.4010701@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com>
Message-ID: <51C9FEC1.6010607@gmail.com>


On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
> On 06/25/2013 11:38 PM, Peter Levart wrote:
>> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
>>> It might be a good idea to turn $powerCache final, not volatile, since
>>> the code will recover anyway. The trouble I'm seeing is weak enough
>>> hardware, which will never see the updated value of cacheLine, always
>>> falling back. Hence, I'm keen to keep "volatile".
>> The worst thing that could happen is that each thread would effectively
>> have it's private cache.
> Right.
>
> That only works if you store the fallback value to cacheLine, and then
> back to powerCache, since the second get...() will possibly re-read the
> stale cacheLine otherwise. Your version did that. Do we want to store
> the retVal?

My version does store the value back (new cacheLine array into 
powerCache slot and the calculated value(s) into existing/new 
cacheLine), so the only possibility to read the seemingly empty 
cacheLine is when another thread resizes it and installs new version. 
This can only happen about 52 times until the resizing factor 1.5 
expands array to length 2^31...

> private static final BigInteger[][] powerCache;
>
> BigInteger getRadixConversionCache(int radix, int exponent) {
>    BigInteger retVal = null;
>    BigInteger[][] pc = powerCache;
>    BigInteger[] cacheLine = pc[radix];
>    int oldSize = cacheLine.length;
>    if (exponent >= oldSize) {
>        cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>        for (int i = oldSize; i <= exponent; i++) {
>            retVal = cacheLine[i - 1].square();
>            cacheLine[i] = retVal;
>        }
>        pc[radix] = cacheLine;
>    } else {
>        retVal = cacheLine[exponent];
>        if (retVal == null) {
>            // data race, element is not available yet,
>            // compute on the fly
>            retVal = BigInteger.valueOf(radix);
>            for (int c = 0; c < exponent; c++) {
>                retVal = retVal.square();
>            }
>            cacheLine[exponent] = retVal;
>        }
>    }
>
> -Aleksey.
>

This is getting similar to my version, but you're not storing 
intermediate values back into cacheLine. Each exponent requested must 
re-compute intermediate values again and again.


Regards, Peter



From aleksey.shipilev at oracle.com  Tue Jun 25 20:54:06 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 26 Jun 2013 00:54:06 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9FEC1.6010607@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
Message-ID: <51CA036E.9050804@oracle.com>

On 06/26/2013 12:34 AM, Peter Levart wrote:
> 
> On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
>> On 06/25/2013 11:38 PM, Peter Levart wrote:
>>> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
>>>> It might be a good idea to turn $powerCache final, not volatile, since
>>>> the code will recover anyway. The trouble I'm seeing is weak enough
>>>> hardware, which will never see the updated value of cacheLine, always
>>>> falling back. Hence, I'm keen to keep "volatile".
>>> The worst thing that could happen is that each thread would effectively
>>> have it's private cache.
>> Right.
>>
>> That only works if you store the fallback value to cacheLine, and then
>> back to powerCache, since the second get...() will possibly re-read the
>> stale cacheLine otherwise. Your version did that. Do we want to store
>> the retVal?
> 
> My version does store the value back (new cacheLine array into
> powerCache slot and the calculated value(s) into existing/new
> cacheLine), so the only possibility to read the seemingly empty
> cacheLine is when another thread resizes it and installs new version.
> This can only happen about 52 times until the resizing factor 1.5
> expands array to length 2^31...
> 
>> private static final BigInteger[][] powerCache;
>>
>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>   BigInteger retVal = null;
>>   BigInteger[][] pc = powerCache;
>>   BigInteger[] cacheLine = pc[radix];
>>   int oldSize = cacheLine.length;
>>   if (exponent >= oldSize) {
>>       cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>       for (int i = oldSize; i <= exponent; i++) {
>>           retVal = cacheLine[i - 1].square();
>>           cacheLine[i] = retVal;
>>       }
>>       pc[radix] = cacheLine;
>>   } else {
>>       retVal = cacheLine[exponent];
>>       if (retVal == null) {
>>           // data race, element is not available yet,
>>           // compute on the fly
>>           retVal = BigInteger.valueOf(radix);
>>           for (int c = 0; c < exponent; c++) {
>>               retVal = retVal.square();
>>           }
>>           cacheLine[exponent] = retVal;
>>       }
>>   }
>>
>> -Aleksey.
>>
> 
> This is getting similar to my version, but you're not storing
> intermediate values back into cacheLine. Each exponent requested must
> re-compute intermediate values again and again.

Sure. But I suspect it does not matter much, since we only do that under
the race which is about to resolve itself, and we "just" need the
transient value.

Anyway, converging our versions further:

private static final BigInteger[][] powerCache;

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger retVal = null;
  BigInteger[][] pc = powerCache;
  BigInteger[] cacheLine = pc[radix];
  int oldSize = cacheLine.length;
  if (exponent >= oldSize) {
      cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
      for (int i = oldSize; i <= exponent; i++) {
          retVal = cacheLine[i - 1].square();
          cacheLine[i] = retVal;
      }
      pc[radix] = cacheLine;
  } else {
      retVal = cacheLine[exponent];
      if (retVal == null) {
          // data race, element is not available yet,
          // compute on the fly, and try
          retVal = BigInteger.valueOf(radix);
          for (int c = 0; c < exponent + 1; c++) {
              cacheLine[c] = retVal;
              retVal = retVal.square();
          }
      }
  }
}

Trying to improve this yields the code very similar to
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018368.html,
although not as effective on slow path:

private static final BigInteger[][] powerCache;

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger retVal = null;
  BigInteger[][] pc = powerCache;
  BigInteger[] cacheLine = pc[radix];
  int oldSize = cacheLine.length;
  if (exponent >= oldSize) {
      cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
  }
  retVal = cacheLine[exponent];
  if (retVal == null) {
      retVal = BigInteger.valueOf(radix);
      for (int i = 0; i < exponent + 1; i++) {
          cacheLine[i] = retVal;
          retVal = retVal.square();
      }
      pc[radix] = cacheLine;
  }
  return retVal;
}

-Aleksey.


From peter.levart at gmail.com  Tue Jun 25 20:56:01 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 22:56:01 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9FEC1.6010607@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
Message-ID: <51CA03E1.3060107@gmail.com>


On 06/25/2013 10:34 PM, Peter Levart wrote:
>
> On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
>> On 06/25/2013 11:38 PM, Peter Levart wrote:
>>> On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
>>>> It might be a good idea to turn $powerCache final, not volatile, since
>>>> the code will recover anyway. The trouble I'm seeing is weak enough
>>>> hardware, which will never see the updated value of cacheLine, always
>>>> falling back. Hence, I'm keen to keep "volatile".
>>> The worst thing that could happen is that each thread would effectively
>>> have it's private cache.
>> Right.
>>
>> That only works if you store the fallback value to cacheLine, and then
>> back to powerCache, since the second get...() will possibly re-read the
>> stale cacheLine otherwise. Your version did that. Do we want to store
>> the retVal?
>
> My version does store the value back (new cacheLine array into 
> powerCache slot and the calculated value(s) into existing/new 
> cacheLine), so the only possibility to read the seemingly empty 
> cacheLine is when another thread resizes it and installs new version. 
> This can only happen about 52 times until the resizing factor 1.5 
> expands array to length 2^31...
>
>> private static final BigInteger[][] powerCache;
>>
>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>    BigInteger retVal = null;
>>    BigInteger[][] pc = powerCache;
>>    BigInteger[] cacheLine = pc[radix];
>>    int oldSize = cacheLine.length;
>>    if (exponent >= oldSize) {
>>        cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>        for (int i = oldSize; i <= exponent; i++) {
>>            retVal = cacheLine[i - 1].square();
>>            cacheLine[i] = retVal;
>>        }
>>        pc[radix] = cacheLine;
>>    } else {
>>        retVal = cacheLine[exponent];
>>        if (retVal == null) {
>>            // data race, element is not available yet,
>>            // compute on the fly
>>            retVal = BigInteger.valueOf(radix);
>>            for (int c = 0; c < exponent; c++) {
>>                retVal = retVal.square();
>>            }
>>            cacheLine[exponent] = retVal;
>>        }
>>    }
>>
>> -Aleksey.
>>
>
> This is getting similar to my version, but you're not storing 
> intermediate values back into cacheLine. Each exponent requested must 
> re-compute intermediate values again and again.

Sorry, you are storing back when resizing. And you are resizing for 
every exponent that is bigger that previous requested (cached). This can 
lead to many resizings.

Besides, I think that this version still has a data-race dereferencing 
array, followed by reading of array elements:

Thread A:
     pc = powerCache;

Thread B:
     pc = powerCache;
     cacheLine = pc[radix];
     oldSize = cacheLine.length;
     // enter if, since exponent >= oldSize
     cacheLine = copyOf(cacheLine, exponent+1);
     // ...for loop filling cacheLine...
     pc[radix] = cacheLine;

Thread A:
     cacheLine = pc[radix]; // this can read new cacheLine constructed 
by Thread B (data-race)
     oldSize = cacheLine.length;
     // enter if, since exponent >= oldSize
     cacheLine = copyOf(cacheLine, exponent+1);  // here the copying can 
read null slots even for indexes < oldSize
     for (int i = oldSize; i <= exponent; i++) {
         retVal = cacheLine[i - 1].square(); // possible NPE!

>
>
> Regards, Peter
>



From aleksey.shipilev at oracle.com  Tue Jun 25 21:06:33 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 26 Jun 2013 01:06:33 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CA03E1.3060107@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
	<51CA03E1.3060107@gmail.com>
Message-ID: <51CA0659.2040002@oracle.com>

On 06/26/2013 12:56 AM, Peter Levart wrote:
> Sorry, you are storing back when resizing. And you are resizing for
> every exponent that is bigger that previous requested (cached). This can
> lead to many resizings.

Dmitry had suggested going back to square one with his approach. I'll
let him post his suggestion (I think it is simpler than both our versions).

-Aleksey.



From stevenschlansker at gmail.com  Tue Jun 25 21:12:02 2013
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 25 Jun 2013 14:12:02 -0700
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CA03E1.3060107@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
	<51CA03E1.3060107@gmail.com>
Message-ID: <365FD64A-7CDD-4B43-A4F4-35042333A5DF@gmail.com>


On Jun 25, 2013, at 1:56 PM, Peter Levart  wrote:
> 
> Sorry, you are storing back when resizing. And you are resizing for every exponent that is bigger that previous requested (cached). This can lead to many resizings.


Hi everyone,

Apologies to butt in, and maybe this is a very stupid suggestion, but is the added complexity and potential for data race-introduced bugs worth the added efficiency over (for example) a ConcurrentMap with a key of "radix << 32 | exponent" ?

It is clearly not as efficient, but it does have the virtue that even mere mortals like myself can understand that it is safe code, and maybe it is "good enough"  :-)

Best,
Steven



From peter.levart at gmail.com  Tue Jun 25 21:21:54 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 25 Jun 2013 23:21:54 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CA036E.9050804@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
	<51CA036E.9050804@oracle.com>
Message-ID: <51CA09F2.6000505@gmail.com>


On 06/25/2013 10:54 PM, Aleksey Shipilev wrote:
> Trying to improve this yields the code very similar to
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018368.html,
> although not as effective on slow path:
>
> private static final BigInteger[][] powerCache;
>
> BigInteger getRadixConversionCache(int radix, int exponent) {
>    BigInteger retVal = null;
>    BigInteger[][] pc = powerCache;
>    BigInteger[] cacheLine = pc[radix];
>    int oldSize = cacheLine.length;
>    if (exponent >= oldSize) {
>        cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>    }
>    retVal = cacheLine[exponent];
>    if (retVal == null) {
>        retVal = BigInteger.valueOf(radix);
>        for (int i = 0; i < exponent + 1; i++) {
>            cacheLine[i] = retVal;
>            retVal = retVal.square();
>        }
>        pc[radix] = cacheLine;
>    }
>    return retVal;
> }
>
> -Aleksey.

I think this is correct from logical standpoint. But not very effective. 
Think of single-threaded usage first. You resize for every exponent that 
is bigger than biggest requested so-far. And each time you request 
exponent that is bigger or equal to the biggest requested so far, you 
recalculate all squares (the last one calculated is not stored!!!).

I think it pays back if you search backwards from requested exponent to 
the biggest non-null slot, and only recalculate those that are not 
calculated yet. The search, although linear, is nothing compared to the 
recalculation of the same number of slots that were searched-back.

Regards, Peter



From jason.uh at oracle.com  Tue Jun 25 21:32:15 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Tue, 25 Jun 2013 21:32:15 +0000
Subject: hg: jdk8/tl/jdk: 8017325: Cleanup of the javadoc  tag in
	java.security.cert
Message-ID: <20130625213236.884644851B@hg.openjdk.java.net>

Changeset: 757290440a2f
Author:    juh
Date:      2013-06-25 14:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/757290440a2f

8017325: Cleanup of the javadoc  tag in java.security.cert
Summary: Convert javadoc ... and ... tags to {@code ...}
Reviewed-by: darcy

! src/share/classes/java/security/cert/CRLException.java
! src/share/classes/java/security/cert/CRLSelector.java
! src/share/classes/java/security/cert/CertPath.java
! src/share/classes/java/security/cert/CertPathBuilder.java
! src/share/classes/java/security/cert/CertPathBuilderException.java
! src/share/classes/java/security/cert/CertPathBuilderResult.java
! src/share/classes/java/security/cert/CertPathBuilderSpi.java
! src/share/classes/java/security/cert/CertPathParameters.java
! src/share/classes/java/security/cert/CertPathValidator.java
! src/share/classes/java/security/cert/CertPathValidatorException.java
! src/share/classes/java/security/cert/CertPathValidatorResult.java
! src/share/classes/java/security/cert/CertPathValidatorSpi.java
! src/share/classes/java/security/cert/CertSelector.java
! src/share/classes/java/security/cert/CertStore.java
! src/share/classes/java/security/cert/CertStoreException.java
! src/share/classes/java/security/cert/CertStoreParameters.java
! src/share/classes/java/security/cert/CertStoreSpi.java
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/java/security/cert/CertificateEncodingException.java
! src/share/classes/java/security/cert/CertificateException.java
! src/share/classes/java/security/cert/CertificateExpiredException.java
! src/share/classes/java/security/cert/CertificateFactory.java
! src/share/classes/java/security/cert/CertificateFactorySpi.java
! src/share/classes/java/security/cert/CertificateNotYetValidException.java
! src/share/classes/java/security/cert/CertificateParsingException.java
! src/share/classes/java/security/cert/CertificateRevokedException.java
! src/share/classes/java/security/cert/CollectionCertStoreParameters.java
! src/share/classes/java/security/cert/Extension.java
! src/share/classes/java/security/cert/LDAPCertStoreParameters.java
! src/share/classes/java/security/cert/PKIXBuilderParameters.java
! src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java
! src/share/classes/java/security/cert/PKIXCertPathChecker.java
! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java
! src/share/classes/java/security/cert/PKIXParameters.java
! src/share/classes/java/security/cert/PKIXReason.java
! src/share/classes/java/security/cert/PolicyNode.java
! src/share/classes/java/security/cert/PolicyQualifierInfo.java
! src/share/classes/java/security/cert/TrustAnchor.java
! src/share/classes/java/security/cert/X509CRL.java
! src/share/classes/java/security/cert/X509CRLEntry.java
! src/share/classes/java/security/cert/X509CRLSelector.java
! src/share/classes/java/security/cert/X509CertSelector.java
! src/share/classes/java/security/cert/X509Certificate.java
! src/share/classes/java/security/cert/X509Extension.java



From jason.uh at oracle.com  Tue Jun 25 21:42:17 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Tue, 25 Jun 2013 21:42:17 +0000
Subject: hg: jdk8/tl/jdk: 8017326: Cleanup of the javadoc  tag in
	java.security.spec
Message-ID: <20130625214240.206054851F@hg.openjdk.java.net>

Changeset: 3700bb58c9a2
Author:    juh
Date:      2013-06-25 14:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3700bb58c9a2

8017326: Cleanup of the javadoc  tag in java.security.spec
Summary: Convert javadoc  and  tags to {@code ...}
Reviewed-by: darcy

! src/share/classes/java/security/spec/DSAGenParameterSpec.java
! src/share/classes/java/security/spec/DSAParameterSpec.java
! src/share/classes/java/security/spec/DSAPrivateKeySpec.java
! src/share/classes/java/security/spec/DSAPublicKeySpec.java
! src/share/classes/java/security/spec/ECFieldF2m.java
! src/share/classes/java/security/spec/ECFieldFp.java
! src/share/classes/java/security/spec/ECGenParameterSpec.java
! src/share/classes/java/security/spec/ECParameterSpec.java
! src/share/classes/java/security/spec/ECPoint.java
! src/share/classes/java/security/spec/ECPrivateKeySpec.java
! src/share/classes/java/security/spec/ECPublicKeySpec.java
! src/share/classes/java/security/spec/EllipticCurve.java
! src/share/classes/java/security/spec/EncodedKeySpec.java
! src/share/classes/java/security/spec/InvalidKeySpecException.java
! src/share/classes/java/security/spec/KeySpec.java
! src/share/classes/java/security/spec/MGF1ParameterSpec.java
! src/share/classes/java/security/spec/PKCS8EncodedKeySpec.java
! src/share/classes/java/security/spec/PSSParameterSpec.java
! src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java
! src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
! src/share/classes/java/security/spec/RSAOtherPrimeInfo.java
! src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java
! src/share/classes/java/security/spec/X509EncodedKeySpec.java



From peter.levart at gmail.com  Tue Jun 25 22:12:13 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 26 Jun 2013 00:12:13 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CA0659.2040002@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com> <51C9F19C.5080103@gmail.com>
	<51C9F46B.4010701@oracle.com> <51C9FEC1.6010607@gmail.com>
	<51CA03E1.3060107@gmail.com> <51CA0659.2040002@oracle.com>
Message-ID: <51CA15BD.6010500@gmail.com>


On 06/25/2013 09:09 PM, Alan Eliasen wrote:
> On 06/25/2013 12:13 PM, Peter Levart wrote:
>>              else { // resizing
>>                  // increase by factor of 1.5 (like ArrayList)
>>                  int newLength = oldLength + (oldLength >> 1);
>     We probably don't ever want to extend any row of this cache any more
> than we need to.  The entries in each row of the cache, say for base 10,
> are 10^(2^n) which obviously grows super-exponentially with n.  (And the
> time to perform each squaring to get successive terms will grow
> quadratically or at least subquadratically on top of that, along with
> memory usage which squares with each additional term.)  So we should
> never resize to more entries in that table than we need, and we should
> try to avoid recalculating entries in that table in multiple threads, as
> the cost to calculate them can be high.
>
>     As I noted years ago, the caching behavior is certainly going to be
> one of the most controversial parts of BigInteger improvements.  :)
>

Hi Alan,

That's only the re-sizing of the array, so that it is not needed to be 
performed on each bigger exponent request. My code never calculates 
entries past the requested exponent, but can re-calculate the same 
entries if races occur. The part about resizing the array could be tuned 
(change the factor 1.5 -> 1 and you get the 
only-resize-to-maximum-requested-size  behaviour). The re-calculation 
when concurrent requests are issued for same slot(s) could be avoided 
with CAS-es combined with locking. Perhaps the first few exponents, 
where the .square()s can be (re)computed relatively fast, could be 
cached optimistically to avoid volatile reads/CAS-es on fast paths. When 
the exponent index reaches certain threshold, the strategy could change 
and instead of normal racy reads/writes of BigInteger elements, we could 
CAS Supplier elements. The Supplier would have a 
synchronized get() method that actually computes the BigInteger and 
returns it and installs the BigInteger into the same slot at the same 
time, so that further accesses only need volatile reads from those slots 
and instanceof BigInteger checks.

Something like that (the 2nd part with Supplier) is implemented in 
java.lang.reflect.Proxy to cache generated proxy classes and makes sure 
that each requested Proxy class is only generated and defined once. This 
case is trickier, because calculation of a particular exponent index 
needs the value from previous exponent index which might be in the 
process of calculation by some other thread, so we need to wait on it to 
finish, but this other thread might be waiting for the third thread 
doing calculation of yet previous exponent, etc... Luckily dependencies 
are ordered so no danger of dead-locks, I think...

Regards, Peter



From peter.levart at gmail.com  Tue Jun 25 22:12:32 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 26 Jun 2013 00:12:32 +0200
Subject: RFR 4641897: Faster string conversion of large integers
In-Reply-To: <51C9EAF6.40201@mindspring.com>
References: 
	<51C421A2.3080903@oracle.com>
	
	<51C47313.9080906@oracle.com>
	
	<51C58172.9030209@oracle.com> <51C58262.6030403@oracle.com>
	<51C9DDDB.5080800@gmail.com> <51C9EAF6.40201@mindspring.com>
Message-ID: <51CA15D0.80503@gmail.com>


On 06/25/2013 09:09 PM, Alan Eliasen wrote:
> On 06/25/2013 12:13 PM, Peter Levart wrote:
>>              else { // resizing
>>                  // increase by factor of 1.5 (like ArrayList)
>>                  int newLength = oldLength + (oldLength >> 1);
>     We probably don't ever want to extend any row of this cache any more
> than we need to.  The entries in each row of the cache, say for base 10,
> are 10^(2^n) which obviously grows super-exponentially with n.  (And the
> time to perform each squaring to get successive terms will grow
> quadratically or at least subquadratically on top of that, along with
> memory usage which squares with each additional term.)  So we should
> never resize to more entries in that table than we need, and we should
> try to avoid recalculating entries in that table in multiple threads, as
> the cost to calculate them can be high.
>
>     As I noted years ago, the caching behavior is certainly going to be
> one of the most controversial parts of BigInteger improvements.  :)
>

Hi Alan, I'll answer in the other thread.

Peter



From mandy.chung at oracle.com  Tue Jun 25 22:42:43 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 25 Jun 2013 15:42:43 -0700
Subject: @CallerSensitive as public API ?
In-Reply-To: 
References: <51C9760F.7000007@gmail.com> <51C9EE5B.8050300@oracle.com>
	
Message-ID: <51CA1CE3.6050203@oracle.com>

On 6/25/13 3:04 PM, David Lloyd wrote:
> We have a use case within our security manager implementation that *can* be solved with the existing getClassContext method, which returns the whole stack, except we don't *need*  the whole stack, just one specific frame.  Maybe SecurityManager is a good place for this API?

Which frame do you need?   How do you use it?

>
> As an aside, getClassContext returns a Class[]; maybe it should be changed to Class[] instead.

Ah.  I can fix that in my fix for 8007035 [1].

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018327.html
> --
> - DML
>
>
> On Jun 25, 2013, at 8:35 PM, Mandy Chung  wrote:
>
>> On 6/25/13 3:50 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> I know that @CallerSensitive annotation was introduced to bring some order to JDK internal plumbings. It's scope was to support JDK internal usage, so it's use is limited to classes loaded by bootstrap or extension class-loaders. In JDK-internal code it is used mainly for implementing security-sensitive decisions. But since the sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, it found it's way out into user code, where at least I know that it is used in two areas:
>>>
>>> 1 - to locate callers in the whole call-stack so that their location in class-path can be reported (Log4J is an example)
>>> 2 - to locate immediate caller so that some resources associated with it can be located and used (for example localization data in GUI applications)
>>>
>>> I don't know how wide-spread 1st usecase is, but the 2nd is common, since it's use enables APIs that need not explicitly pass-in the calling class in order to locate resources associated with it (and/or the class-loader of it). So it would be nice to have such supported API in JDK8 at least.
>> It's good to know these use cases.  We leave the method in 7 update release so as to allow time for applications to transition and also determine any use case that the SE API should provide if there is no replacement for it.
>>
>>> I'm asking here, to hear any arguments against making such API supported and public. Are there any security or other issues? If there aren't, what steps should be taken to introduce such API in the JDK8 timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving @CallerSensitive to a supported package + enabling it to mark methods in any class (not just system and ext classes)...
>> Besides providing a method returning the caller's class, I'd like to consider what other options we have and different use cases could be satisfied by different API.  For #2, the problem is that the API to find a resource, it requires to use the ClassLoader with the right visibility (the caller's class loader).  This is similiar to 8013839 : Enhance Logger API for handling of resource bundles [1]. For example, a static method Class.getResource to use the caller's class loader to find the given resource might be an alternative?
>>
>> About the timeframe, the API freeze date [2] is Oct 10.  If the API is simple and small effort (test development, security assessement, etc), there is chance to get that in for jdk8.
>>
>> Mandy
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
>> [2] http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze
>>



From weijun.wang at oracle.com  Tue Jun 25 23:31:53 2013
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 26 Jun 2013 07:31:53 +0800
Subject: test with a 3rd party jar file?
In-Reply-To: <51C9CEF8.2080300@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8ECEF.6080200@oracle.com>
	<51C9CEF8.2080300@oracle.com>
Message-ID: <59154D77-110A-49DF-AEFE-D79A61E01A2F@oracle.com>

That should be enough. Then you only need to waitFor it.

--Max

? Jun 26, 2013?1:10 AM?huizhe wang  ???

> Max,
> 
> Can you explain how to use your test library to run a simple test such as the one attached with a 3rd party jar on bootclasspath?
> 
> e.g.
> Proc pc = Proc.create("Test")
>          .args("-Xbootclasspath/p:"+pathtoXercesImpljar)
>          .start();
> is that how 3rd party jar file can be put on the bootclasspath? what else needs to be done after
> that in order carry out the test?
> 
> Thanks,
> Joe
> 
> On 6/24/2013 6:05 PM, Weijun Wang wrote:
>> On 6/25/13 6:42 AM, Rob McKenna wrote:
>>> Some interesting conversations were had lately about shell scripts
>>> during Joe Darcy's recent infrastructure tech talk. In particular around
>>> the idea of a "jdk.testing" package to provide libraries that would help
>>> with the types of operations seen in shell scripts. I'm really hoping to
>>> spend some time on this myself over the coming weeks. (in an effort to
>>> at least understand why we need shell scripts and whether we could do
>>> something else instead)
>> 
>> Oh, I've recently invented a new wheel on loading processes and make them interact with each other
>> 
>> 
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java 
>> 
>> An example here
>> 
>> 
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java
> 
> 
>> 
>> --Max
>> 
>>> 
>>>     -Rob
> 
> 


From nicholas+openjdk at nicholaswilliams.net  Tue Jun 25 23:44:21 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Tue, 25 Jun 2013 18:44:21 -0500
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9760F.7000007@gmail.com>
References: <51C9760F.7000007@gmail.com>
Message-ID: <5DDA5F5D-F7AC-4B98-B076-4F26C642C5B5@nicholaswilliams.net>


On Jun 25, 2013, at 5:50 AM, Peter Levart wrote:

> Hi,
> 
> I know that @CallerSensitive annotation was introduced to bring some order to JDK internal plumbings. It's scope was to support JDK internal usage, so it's use is limited to classes loaded by bootstrap or extension class-loaders. In JDK-internal code it is used mainly for implementing security-sensitive decisions. But since the sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, it found it's way out into user code, where at least I know that it is used in two areas:
> 
> 1 - to locate callers in the whole call-stack so that their location in class-path can be reported (Log4J is an example)
> 2 - to locate immediate caller so that some resources associated with it can be located and used (for example localization data in GUI applications)
> 
> I don't know how wide-spread 1st usecase is, but the 2nd is common, since it's use enables APIs that need not explicitly pass-in the calling class in order to locate resources associated with it (and/or the class-loader of it). So it would be nice to have such supported API in JDK8 at least.
> 
> I'm asking here, to hear any arguments against making such API supported and public. Are there any security or other issues? If there aren't, what steps should be taken to introduce such API in the JDK8 timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving @CallerSensitive to a supported package + enabling it to mark methods in any class (not just system and ext classes)...
> 
> Regards, Peter

I'm all for making this API public, and I can see many uses and advantages to doing so. I would point out, however, that #1 actually has two parts:

1.A - To identify callers (Class, not just name) in the _current_ call stack (currently supported, albeit in a difficult-to-use way, using Class[] SecurityManager#getClassContext()).
1.B - To identify frames (Class, not just name) in the stack generated _when throwing an exception_ (not currently supported at all).

For those of us working on Log4j, #1.B is the biggest priority by orders of magnitude over #1.A and #2. See the existing discussion [1] for more info. I think the current most-viable options on the table (which some people had concerns about) were A) add the Class to StackTraceElement and B) add a StackFrame class and add a StackFrame[] getStackFrames method to Throwable (similar to StackTraceElement[] getStackTrace()). StackFrame would contain Class getFrameClass(), Executable getExecutable(), String getFileName(), int getLineNumber(), and boolean isNative().

As for #2, I would say this: @CallerSensitive is awesome; however, you can't annotate a class @CallerSensitive and it be runnable on Java 6. As much as it sucks, major projects like Log4j will have to support Java 6 for at least another 4-5 years. However, you _can_ conditionally use a Java 8 API and the code still be runnable on Java 6 (as long as there's backup code that executes in the absence of this API). So I would ask that there be a getCallerClass or equivalent method that works with an int skipFrames parameter (like now) or returns a Class[] _in addition to_ a no-arg getCallerClass method that uses @CallerSensitive.

My $0.02.

Nick

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018049.html

From brian.burkhalter at oracle.com  Wed Jun 26 00:13:33 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Jun 2013 17:13:33 -0700
Subject: RFC 7019078: Double.parseDouble() converts some subnormal numbers
	incorrectly
Message-ID: <7851D324-1E4F-479E-934F-E3E0AED899E6@oracle.com>

The test case in the description of this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7019078

passes after the integration of this changeset

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a88f6f4d279f

except when the exponent has the value -1074. Here is the pertinent code from the test:

            BigDecimal TWO = BigDecimal.valueOf(2);
            BigDecimal ulp_BD = new BigDecimal(Double.MIN_VALUE);
            double d = Math.scalb(1.0, -1074); // == Double.MIN_VALUE

            BigDecimal d_BD = new BigDecimal(d);

            BigDecimal lowerBound = d_BD.subtract(ulp_BD.divide(TWO));
            BigDecimal upperBound = d_BD.add(ulp_BD.divide(TWO));

            double convertedLowerBound = Double.parseDouble(lowerBound.toString());
            double convertedUpperBound = Double.parseDouble(upperBound.toString());

            if (convertedLowerBound != d) {
                System.out.printf("Exponent %d, unexpected lower bound converted to %a, not %a.%n",
                        i, convertedLowerBound, d);
            }

            if (convertedUpperBound != d) {
                System.out.printf("Exponent %d, unexpected upper bound converted to %a, not %a.%n",
                        i, convertedUpperBound, d);
            }

The output of the above is

Exponent -1074, unexpected lower bound converted to 0x0.0p0, not 0x0.0000000000001p-1022.
Exponent -1074, unexpected upper bound converted to 0x0.0000000000002p-1022, not 0x0.0000000000001p-1022.

For the case of 2^(-1074), lowerBound is 2^(-1074) - 2^(-1075) = Double.MIN_VALUE/2 which per the IEEE 754 round-to-nearest rule rounds correctly to zero. For this case, upperBound is equivalent to 2^(-1074) + 2^(-1075) which is halfway between 2^(-1074) and 2*2^(-1074). As round-to-nearest mandates that the tie with the least significant bit equal to zero be chosen, the correct outcome after rounding is 2*2^(-1074) which is what is obtained. The test case is therefore incorrect for both lower and upper bounds when the exponent is -1074.

As a result of all but one case having been fixed and that last case being an incorrect test, this issue may be closed as a duplicate unless there are objections to the contrary.

Brian

From heinz at javaspecialists.eu  Wed Jun 26 01:10:51 2013
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Wed, 26 Jun 2013 04:10:51 +0300
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9760F.7000007@gmail.com>
References: <51C9760F.7000007@gmail.com>
Message-ID: <51CA3F9B.6070702@javaspecialists.eu>

Hi Peter,

here is another use case, where someone might want to use this:

3 - in a static context, find out what the class is that you are in.

For example, if you want to create a logger, instead of doing this:

private static final Logger log = Logger.getLogger(SomeClass.class);

we could instead have a magic method that figures out what class this is 
being called from and then sets the class automatically.

There are two other ways to do this, but they are a lot slower than 
Reflection.getCallerClass():

1. http://www.javaspecialists.eu/archive/Issue137.html - create an 
exception and figure out who the calling class is

2. Or we can use the SecurityManager to get us a stack of contexts.

For example, in the exercises for my courses, some students had problems 
with the JUnit plugin.  So each test case also contains the main method, 
but it is always the same:

    public static void main(String[] args) {
        UnitTestRunner.run();
    }

My UnitTestRunner then depends on the security manager to decide what 
the actual class is and then uses the JUnit4TestAdapter to call the methods:

import junit.framework.*;
import junit.textui.*;

public class UnitTestRunner {
    private static void run(Class clazz) {
        System.out.println("Running unit tests for " + clazz);
        TestRunner.run(new JUnit4TestAdapter(clazz));
    }

    public static void run() {
        MySecurityManager sm = new MySecurityManager();
        Class clazz = sm.getClassContext()[2];
        run(clazz);
    }

    private static class MySecurityManager extends SecurityManager {
        public Class[] getClassContext() {
            return super.getClassContext();
        }
    }
}

Works like a charm.  Fortunately this is not affected by the 
Reflection.getCallerClass() bug.

Just my 2c :-)

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Java Champion 2005-2013
JavaOne Rock Star Speaker 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz



Peter Levart wrote:
> Hi,
>
> I know that @CallerSensitive annotation was introduced to bring some 
> order to JDK internal plumbings. It's scope was to support JDK 
> internal usage, so it's use is limited to classes loaded by bootstrap 
> or extension class-loaders. In JDK-internal code it is used mainly for 
> implementing security-sensitive decisions. But since the 
> sun.reflect.Reflection.getCallerClass(int) was public and 
> unrestricted, it found it's way out into user code, where at least I 
> know that it is used in two areas:
>
> 1 - to locate callers in the whole call-stack so that their location 
> in class-path can be reported (Log4J is an example)
> 2 - to locate immediate caller so that some resources associated with 
> it can be located and used (for example localization data in GUI 
> applications)
>
> I don't know how wide-spread 1st usecase is, but the 2nd is common, 
> since it's use enables APIs that need not explicitly pass-in the 
> calling class in order to locate resources associated with it (and/or 
> the class-loader of it). So it would be nice to have such supported 
> API in JDK8 at least.
>
> I'm asking here, to hear any arguments against making such API 
> supported and public. Are there any security or other issues? If there 
> aren't, what steps should be taken to introduce such API in the JDK8 
> timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() 
> and moving @CallerSensitive to a supported package + enabling it to 
> mark methods in any class (not just system and ext classes)...
>
> Regards, Peter
>
>


From brian.burkhalter at oracle.com  Wed Jun 26 01:18:50 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Jun 2013 18:18:50 -0700
Subject: RFC 6910473: BigInteger negative bit length, value range,
	and future prospects
Message-ID: <3C28D178-09DF-4CBC-93B2-272C0407D27C@oracle.com>

This request for comment regards this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6910473
BigInteger.bigLength() may return negative value for large numbers

but more importantly Dmitry's thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018345.html
What is the range of BigInteger values?

The issue may be fixed superficially simply by throwing an ArithmeticException if the bit length as an int would be negative. A better fix suggested both in the issue description and in the aforementioned thread (option 1 of 3), is to define BigInteger to support a limited range and to clamp to that range in the constructor, throwing an ArithmeticException if the supplied parameter(s) would cause the BigInteger to overflow. This check would be relatively inexpensive. The suggested constraint range is
[ -pow(2, pow(2,31) - 1), pow(2, pow(2,31) - 1) )
This constraint would guarantee that all BigInteger instances are capable of accurately returning their properties such as bit length, bit count, etc.

This naturally would require a minor specification change to BigInteger. The question is whether this change would limit any future developments of this and related classes. For example, one could envision BigInteger supporting bit lengths representable by a long instead of an int. In this case the second option would be preferable.

It has been suggested that an alternative to extending the ranges supported by BigInteger would be to define a different class altogether to handle the larger ranges, keeping BigInteger as a well-specified API for the ranges it supports. Other related classes for arbitrary precision binary floating point and rational numbers might also be considered.

In summary the specific questions being posed here are:

1) what is the general opinion on clamping the range of BigInteger and the various options suggested at the end of

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018345.html ?

2) what are the forward looking thoughts on handling integers outside the current BigInteger range?

From a practical point of view, any changes need to be considered with respect to what may be done in the short term (JDK 8) versus the long (JDK 9), so to speak.

Thanks,

Brian

From huizhe.wang at oracle.com  Wed Jun 26 01:32:09 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 25 Jun 2013 18:32:09 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <59154D77-110A-49DF-AEFE-D79A61E01A2F@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8ECEF.6080200@oracle.com>
	<51C9CEF8.2080300@oracle.com>
	<59154D77-110A-49DF-AEFE-D79A61E01A2F@oracle.com>
Message-ID: <51CA4499.7030708@oracle.com>

Thanks! I'll give it a try. Do you plan to backport this to jdk7?

-Joe

On 6/25/2013 4:31 PM, Wang Weijun wrote:
> That should be enough. Then you only need to waitFor it.
>
> --Max
>
> ? Jun 26, 2013?1:10 AM?huizhe wang  ???
>
>> Max,
>>
>> Can you explain how to use your test library to run a simple test such as the one attached with a 3rd party jar on bootclasspath?
>>
>> e.g.
>> Proc pc = Proc.create("Test")
>>          .args("-Xbootclasspath/p:"+pathtoXercesImpljar)
>>          .start();
>> is that how 3rd party jar file can be put on the bootclasspath? what else needs to be done after
>> that in order carry out the test?
>>
>> Thanks,
>> Joe
>>
>> On 6/24/2013 6:05 PM, Weijun Wang wrote:
>>> On 6/25/13 6:42 AM, Rob McKenna wrote:
>>>> Some interesting conversations were had lately about shell scripts
>>>> during Joe Darcy's recent infrastructure tech talk. In particular around
>>>> the idea of a "jdk.testing" package to provide libraries that would help
>>>> with the types of operations seen in shell scripts. I'm really hoping to
>>>> spend some time on this myself over the coming weeks. (in an effort to
>>>> at least understand why we need shell scripts and whether we could do
>>>> something else instead)
>>> Oh, I've recently invented a new wheel on loading processes and make them interact with each other
>>>
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java 
>>>
>>> An example here
>>>
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java
>>
>>> --Max
>>>
>>>>     -Rob
>> 



From weijun.wang at oracle.com  Wed Jun 26 01:33:07 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 26 Jun 2013 09:33:07 +0800
Subject: test with a 3rd party jar file?
In-Reply-To: <51CA4499.7030708@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8ECEF.6080200@oracle.com>
	<51C9CEF8.2080300@oracle.com>
	<59154D77-110A-49DF-AEFE-D79A61E01A2F@oracle.com>
	<51CA4499.7030708@oracle.com>
Message-ID: <51CA44D3.6000209@oracle.com>



On 6/26/13 9:32 AM, huizhe wang wrote:
> Thanks! I'll give it a try. Do you plan to backport this to jdk7?

No, but you can smuggle it there inside your test.

--Max

> 
> -Joe
> 
> On 6/25/2013 4:31 PM, Wang Weijun wrote:
>> That should be enough. Then you only need to waitFor it.
>>
>> --Max
>>
>> ? Jun 26, 2013?1:10 AM?huizhe wang  ???
>>
>>> Max,
>>>
>>> Can you explain how to use your test library to run a simple test such as the one attached with a 3rd party jar on bootclasspath?
>>>
>>> e.g.
>>> Proc pc = Proc.create("Test")
>>>           .args("-Xbootclasspath/p:"+pathtoXercesImpljar)
>>>           .start();
>>> is that how 3rd party jar file can be put on the bootclasspath? what else needs to be done after
>>> that in order carry out the test?
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 6/24/2013 6:05 PM, Weijun Wang wrote:
>>>> On 6/25/13 6:42 AM, Rob McKenna wrote:
>>>>> Some interesting conversations were had lately about shell scripts
>>>>> during Joe Darcy's recent infrastructure tech talk. In particular around
>>>>> the idea of a "jdk.testing" package to provide libraries that would help
>>>>> with the types of operations seen in shell scripts. I'm really hoping to
>>>>> spend some time on this myself over the coming weeks. (in an effort to
>>>>> at least understand why we need shell scripts and whether we could do
>>>>> something else instead)
>>>> Oh, I've recently invented a new wheel on loading processes and make them interact with each other
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java
>>>>
>>>> An example here
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java
>>>
>>>> --Max
>>>>
>>>>>      -Rob
>>> 
> 


From weijun.wang at oracle.com  Wed Jun 26 01:39:10 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 26 Jun 2013 09:39:10 +0800
Subject: test with a 3rd party jar file?
In-Reply-To: <51CA44D3.6000209@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8ECEF.6080200@oracle.com>
	<51C9CEF8.2080300@oracle.com>
	<59154D77-110A-49DF-AEFE-D79A61E01A2F@oracle.com>
	<51CA4499.7030708@oracle.com> <51CA44D3.6000209@oracle.com>
Message-ID: <51CA463E.6050800@oracle.com>

Oh, there is another test library with similar purpose at

  https://jbs.oracle.com/bugs/browse/JDK-8007142

and it is already on all versions of java.

It can launch a Java process, wait for it to finish, and collect all the
output (stdout and stderr). Mine takes care of stdin and focus on
inter-process interaction. Maybe you don't need it.

--Max

On 6/26/13 9:33 AM, Weijun Wang wrote:
> 
> 
> On 6/26/13 9:32 AM, huizhe wang wrote:
>> Thanks! I'll give it a try. Do you plan to backport this to jdk7?
> 
> No, but you can smuggle it there inside your test.
> 
> --Max
> 
>>
>> -Joe
>>
>> On 6/25/2013 4:31 PM, Wang Weijun wrote:
>>> That should be enough. Then you only need to waitFor it.
>>>
>>> --Max
>>>
>>> ? Jun 26, 2013?1:10 AM?huizhe wang  ???
>>>
>>>> Max,
>>>>
>>>> Can you explain how to use your test library to run a simple test such as the one attached with a 3rd party jar on bootclasspath?
>>>>
>>>> e.g.
>>>> Proc pc = Proc.create("Test")
>>>>            .args("-Xbootclasspath/p:"+pathtoXercesImpljar)
>>>>            .start();
>>>> is that how 3rd party jar file can be put on the bootclasspath? what else needs to be done after
>>>> that in order carry out the test?
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 6/24/2013 6:05 PM, Weijun Wang wrote:
>>>>> On 6/25/13 6:42 AM, Rob McKenna wrote:
>>>>>> Some interesting conversations were had lately about shell scripts
>>>>>> during Joe Darcy's recent infrastructure tech talk. In particular around
>>>>>> the idea of a "jdk.testing" package to provide libraries that would help
>>>>>> with the types of operations seen in shell scripts. I'm really hoping to
>>>>>> spend some time on this myself over the coming weeks. (in an effort to
>>>>>> at least understand why we need shell scripts and whether we could do
>>>>>> something else instead)
>>>>> Oh, I've recently invented a new wheel on loading processes and make them interact with each other
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/java/security/testlibrary/Proc.java
>>>>>
>>>>> An example here
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/bb2e67628dc0/test/sun/security/krb5/auto/BasicProc.java
>>>>
>>>>> --Max
>>>>>
>>>>>>       -Rob
>>>> 
>>


From dmitry.nadezhin at gmail.com  Wed Jun 26 03:31:52 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Wed, 26 Jun 2013 07:31:52 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51C9F537.1050002@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
Message-ID: 

We have two versions after private discussion with Aleksey.

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger[][] pc = powerCache; // volatile read
  BigInteger[] cacheLine = pc[radix];
  if (exponent < cacheLine.length)
      return cacheLine[exponent];

  int oldSize = cacheLine.length;
  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
  for (int i = oldSize; i < exponent + 1; i++)
      cacheLine[i] = cacheLine[i - 1].square();

  pc = Arrays.copyOf(powerCache);
  pc[radix] = cacheLine;
  powerCache = pc; // volatile write, publish
  return cacheLine[exponent];
}

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger[][] pc = powerCache; // volatile read
  BigInteger[] cacheLine = pc[radix];
  if (exponent < cacheLine.length)
      return cacheLine[exponent];

  int oldSize = cacheLine.length;
  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
  for (int i = oldSize; i < exponent + 1; i++)
       cacheLine[i] = cacheLine[i - 1].square();

  synchronized (BigInteger.class) {
    if (powerCache[radix].length < cacheLine.length) {
      pc = Arrays.copyOf(powerCache);
      pc[radix] = cacheLine;
      powerCache = pc; // volatile write, publish
    }
  }
  return powerCache[radix][exponent];
}

The first version is simpler but sometimes a thread may discard powers with
larger exponents computed by another thread.
A thread may discard only powers computed by itself In the second version.


On Tue, Jun 25, 2013 at 11:53 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
> > What about such code ?
> >
> > BigInteger getRadixConversionCache(int radix, int exponent) {
> >   BigInteger retVal = null;
> >   BigInteger[][] pc = powerCache; // volatile read
> >   BigInteger[] cacheLine = pc[radix];
> >   int oldSize = cacheLine.length;
> >   if (exponent >= oldSize) {
> >       cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
> >       for (int i = oldSize; i <= exponent; i++) {
> >           retVal = cacheLine[i - 1].square();
> >           cacheLine[i] = retVal;
> >       }
> >       synchronized (pc) {
> >         if (pc[radix].length < cacheLine.length) {
> >           pc[radix] = cacheLine;
> >           powerCache = pc; // volatile write, publish
> >         }
> >       }
> >   } else {
> >       retVal = cacheLine[exponent];
> >   }
> >   return retVal;
> > }
>
> Still the same race. The reader thread sees the full-length cacheLine
> early, but the elements are not yet there.
>
> > Is dummy volatile write necessary inside synchronized block ?
> >           powerCache = pc; // volatile write, publish
> >
>
> Yes, since you need to have the matched synchronized(pc) otherwise to
> produce the pairwise "acquire".
>
> -Aleksey.
>
>


From yong.huang at oracle.com  Wed Jun 26 04:06:06 2013
From: yong.huang at oracle.com (yong.huang at oracle.com)
Date: Wed, 26 Jun 2013 04:06:06 +0000
Subject: hg: jdk8/tl/jdk: 8013836: getFirstDayOfWeek reports wrong day for
	pt-BR locale
Message-ID: <20130626040648.845E048532@hg.openjdk.java.net>

Changeset: 510035b7bbbb
Author:    yhuang
Date:      2013-06-25 21:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/510035b7bbbb

8013836: getFirstDayOfWeek reports wrong day for pt-BR locale
Reviewed-by: naoto

+ src/share/classes/sun/util/resources/pt/CalendarData_pt_BR.properties
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java



From aleksey.shipilev at oracle.com  Wed Jun 26 06:31:11 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 26 Jun 2013 10:31:11 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
Message-ID: <8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>

On 26.06.2013, at 7:31, Dmitry Nadezhin  wrote:

> We have two versions after private discussion with Aleksey.
> 
> BigInteger getRadixConversionCache(int radix, int exponent) {
>  BigInteger[][] pc = powerCache; // volatile read
>  BigInteger[] cacheLine = pc[radix];
>  if (exponent < cacheLine.length)
>      return cacheLine[exponent];
> 
>  int oldSize = cacheLine.length;
>  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>  for (int i = oldSize; i < exponent + 1; i++)
>      cacheLine[i] = cacheLine[i - 1].square();
> 
>  pc = Arrays.copyOf(powerCache);
>  pc[radix] = cacheLine;
>  powerCache = pc; // volatile write, publish
>  return cacheLine[exponent];
> }

Thanks, I like this version a lot better. We could check for the existing cacheLine.length right before installing the new one, so the opportunity to overwrite larger cacheLine would be minimal, but I do think the probability of unlucky timing is very low, and the argument is moot :) Let's keep it simple.

-Aleksey.

From dmitry.nadezhin at gmail.com  Wed Jun 26 06:53:24 2013
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Wed, 26 Jun 2013 10:53:24 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
Message-ID: 

> We could check for the existing cacheLine.length right before installing
the new one

Do you mean something like this ?

BigInteger getRadixConversionCache(int radix, int exponent) {
  BigInteger[] cacheLine = powerCache[radix]; // volatile read
  if (exponent < cacheLine.length)
     return cacheLine[exponent];

  int oldLength = cacheLine.length;
  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
  for (int i = oldLength; i < exponent + 1; i++)
     cacheLine[i] = cacheLine[i - 1].square();

  if (exponent >= powerCache[radix].length) { // volatile read again
    BigInteger[][] pc = Arrays.copyOf(powerCache);
    pc[radix] = cacheLine;
    powerCache = pc; // volatile write, publish
  }
  return cacheLine[exponent];
 }



On Wed, Jun 26, 2013 at 10:31 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 26.06.2013, at 7:31, Dmitry Nadezhin  wrote:
>
> > We have two versions after private discussion with Aleksey.
> >
> > BigInteger getRadixConversionCache(int radix, int exponent) {
> >  BigInteger[][] pc = powerCache; // volatile read
> >  BigInteger[] cacheLine = pc[radix];
> >  if (exponent < cacheLine.length)
> >      return cacheLine[exponent];
> >
> >  int oldSize = cacheLine.length;
> >  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
> >  for (int i = oldSize; i < exponent + 1; i++)
> >      cacheLine[i] = cacheLine[i - 1].square();
> >
> >  pc = Arrays.copyOf(powerCache);
> >  pc[radix] = cacheLine;
> >  powerCache = pc; // volatile write, publish
> >  return cacheLine[exponent];
> > }
>
> Thanks, I like this version a lot better. We could check for the existing
> cacheLine.length right before installing the new one, so the opportunity to
> overwrite larger cacheLine would be minimal, but I do think the probability
> of unlucky timing is very low, and the argument is moot :) Let's keep it
> simple.
>
> -Aleksey.


From aleksey.shipilev at oracle.com  Wed Jun 26 07:05:10 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 26 Jun 2013 11:05:10 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
Message-ID: <604A3175-3ABA-4BD2-9283-067534301489@oracle.com>

Yes, like that.

-Aleksey

On 26.06.2013, at 10:53, Dmitry Nadezhin  wrote:

>> We could check for the existing cacheLine.length right before installing
> the new one
> 
> Do you mean something like this ?
> 
> BigInteger getRadixConversionCache(int radix, int exponent) {
>  BigInteger[] cacheLine = powerCache[radix]; // volatile read
>  if (exponent < cacheLine.length)
>     return cacheLine[exponent];
> 
>  int oldLength = cacheLine.length;
>  cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>  for (int i = oldLength; i < exponent + 1; i++)
>     cacheLine[i] = cacheLine[i - 1].square();
> 
>  if (exponent >= powerCache[radix].length) { // volatile read again
>    BigInteger[][] pc = Arrays.copyOf(powerCache);
>    pc[radix] = cacheLine;
>    powerCache = pc; // volatile write, publish
>  }
>  return cacheLine[exponent];
> }
> 
> 
> 
> On Wed, Jun 26, 2013 at 10:31 AM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
> 
>> On 26.06.2013, at 7:31, Dmitry Nadezhin  wrote:
>> 
>>> We have two versions after private discussion with Aleksey.
>>> 
>>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>> BigInteger[][] pc = powerCache; // volatile read
>>> BigInteger[] cacheLine = pc[radix];
>>> if (exponent < cacheLine.length)
>>>     return cacheLine[exponent];
>>> 
>>> int oldSize = cacheLine.length;
>>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>> for (int i = oldSize; i < exponent + 1; i++)
>>>     cacheLine[i] = cacheLine[i - 1].square();
>>> 
>>> pc = Arrays.copyOf(powerCache);
>>> pc[radix] = cacheLine;
>>> powerCache = pc; // volatile write, publish
>>> return cacheLine[exponent];
>>> }
>> 
>> Thanks, I like this version a lot better. We could check for the existing
>> cacheLine.length right before installing the new one, so the opportunity to
>> overwrite larger cacheLine would be minimal, but I do think the probability
>> of unlucky timing is very low, and the argument is moot :) Let's keep it
>> simple.
>> 
>> -Aleksey.


From henry.jen at oracle.com  Wed Jun 26 07:55:12 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 26 Jun 2013 00:55:12 -0700
Subject: RFR (3rd)  8009736: Comparator API cleanup
Message-ID: <51CA9E60.6060108@oracle.com>

Hi,

Thanks for all the reviewing, hopefully this would be the last round as
we addressed feedbacks.

Mostly the difference from last round is javadoc[1], the only code
change[2] is that we override the default method of
Comparator.reversed() for natural/reverse order comparator in
Collections and Comparators as Peter Levart suggested.

[1] http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c78083093dab
[2] http://hg.openjdk.java.net/lambda/lambda/jdk/rev/85308d92a4d6

Cheers,
Henry


From paul.sandoz at oracle.com  Wed Jun 26 08:20:19 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 26 Jun 2013 10:20:19 +0200
Subject: RFR (3rd)  8009736: Comparator API cleanup
In-Reply-To: <51CA9E60.6060108@oracle.com>
References: <51CA9E60.6060108@oracle.com>
Message-ID: <2340B783-A56F-45E6-9A85-6A3087E1DCCF@oracle.com>

HI Henry,

I think this is good to push, and we can tweak other stuff as required with further commits.

I can push for you if you like.

Paul.

On Jun 26, 2013, at 9:55 AM, Henry Jen  wrote:

> Hi,
> 
> Thanks for all the reviewing, hopefully this would be the last round as
> we addressed feedbacks.
> 
> Mostly the difference from last round is javadoc[1], the only code
> change[2] is that we override the default method of
> Comparator.reversed() for natural/reverse order comparator in
> Collections and Comparators as Peter Levart suggested.
> 
> [1] http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c78083093dab
> [2] http://hg.openjdk.java.net/lambda/lambda/jdk/rev/85308d92a4d6
> 
> Cheers,
> Henry



From forax at univ-mlv.fr  Wed Jun 26 08:34:42 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 26 Jun 2013 10:34:42 +0200
Subject: @CallerSensitive as public API ?
In-Reply-To: <51CA3F9B.6070702@javaspecialists.eu>
References: <51C9760F.7000007@gmail.com> <51CA3F9B.6070702@javaspecialists.eu>
Message-ID: <51CAA7A2.6040602@univ-mlv.fr>

On 06/26/2013 03:10 AM, Dr Heinz M. Kabutz wrote:
> Hi Peter,
>
> here is another use case, where someone might want to use this:
>
> 3 - in a static context, find out what the class is that you are in.
>
> For example, if you want to create a logger, instead of doing this:
>
> private static final Logger log = Logger.getLogger(SomeClass.class);
>
> we could instead have a magic method that figures out what class this 
> is being called from and then sets the class automatically.
>
> There are two other ways to do this, but they are a lot slower than 
> Reflection.getCallerClass():
>
> 1. http://www.javaspecialists.eu/archive/Issue137.html - create an 
> exception and figure out who the calling class is
>
> 2. Or we can use the SecurityManager to get us a stack of contexts.
>
> For example, in the exercises for my courses, some students had 
> problems with the JUnit plugin.  So each test case also contains the 
> main method, but it is always the same:
>
>    public static void main(String[] args) {
>        UnitTestRunner.run();
>    }
>
> My UnitTestRunner then depends on the security manager to decide what 
> the actual class is and then uses the JUnit4TestAdapter to call the 
> methods:
>
> import junit.framework.*;
> import junit.textui.*;
>
> public class UnitTestRunner {
>    private static void run(Class clazz) {
>        System.out.println("Running unit tests for " + clazz);
>        TestRunner.run(new JUnit4TestAdapter(clazz));
>    }
>
>    public static void run() {
>        MySecurityManager sm = new MySecurityManager();
>        Class clazz = sm.getClassContext()[2];
>        run(clazz);
>    }
>
>    private static class MySecurityManager extends SecurityManager {
>        public Class[] getClassContext() {
>            return super.getClassContext();
>        }
>    }
> }
>
> Works like a charm.  Fortunately this is not affected by the 
> Reflection.getCallerClass() bug.
>
> Just my 2c :-)
>
> Regards
>
> Heinz

Hi Heinz,
You can also use the JSR 292 Lookup object
   MethodHandles.lookup().lookupClass()

cheers,
R?mi





From heinz at javaspecialists.eu  Wed Jun 26 09:40:24 2013
From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz)
Date: Wed, 26 Jun 2013 12:40:24 +0300
Subject: @CallerSensitive as public API ?
In-Reply-To: <51CAA7A2.6040602@univ-mlv.fr>
References: <51C9760F.7000007@gmail.com> <51CA3F9B.6070702@javaspecialists.eu>
	<51CAA7A2.6040602@univ-mlv.fr>
Message-ID: <51CAB708.40502@javaspecialists.eu>



Remi Forax wrote:
> On 06/26/2013 03:10 AM, Dr Heinz M. Kabutz wrote:
>> Hi Peter,
>>
>> here is another use case, where someone might want to use this:
>>
>> 3 - in a static context, find out what the class is that you are in.
>>
>> For example, if you want to create a logger, instead of doing this:
>>
>> private static final Logger log = Logger.getLogger(SomeClass.class);
>>
>> we could instead have a magic method that figures out what class this 
>> is being called from and then sets the class automatically.
>>
>> There are two other ways to do this, but they are a lot slower than 
>> Reflection.getCallerClass():
>>
>> 1. http://www.javaspecialists.eu/archive/Issue137.html - create an 
>> exception and figure out who the calling class is
>>
>> 2. Or we can use the SecurityManager to get us a stack of contexts.
>>
>> For example, in the exercises for my courses, some students had 
>> problems with the JUnit plugin.  So each test case also contains the 
>> main method, but it is always the same:
>>
>>    public static void main(String[] args) {
>>        UnitTestRunner.run();
>>    }
>>
>> My UnitTestRunner then depends on the security manager to decide what 
>> the actual class is and then uses the JUnit4TestAdapter to call the 
>> methods:
>>
>> import junit.framework.*;
>> import junit.textui.*;
>>
>> public class UnitTestRunner {
>>    private static void run(Class clazz) {
>>        System.out.println("Running unit tests for " + clazz);
>>        TestRunner.run(new JUnit4TestAdapter(clazz));
>>    }
>>
>>    public static void run() {
>>        MySecurityManager sm = new MySecurityManager();
>>        Class clazz = sm.getClassContext()[2];
>>        run(clazz);
>>    }
>>
>>    private static class MySecurityManager extends SecurityManager {
>>        public Class[] getClassContext() {
>>            return super.getClassContext();
>>        }
>>    }
>> }
>>
>> Works like a charm.  Fortunately this is not affected by the 
>> Reflection.getCallerClass() bug.
>>
>> Just my 2c :-)
>>
>> Regards
>>
>> Heinz
>
> Hi Heinz,
> You can also use the JSR 292 Lookup object
>   MethodHandles.lookup().lookupClass()
>
Brilliant, thanks R?mi!  I've learned something new :-)

However, in this case it would not work as I need to find the calling 
class, not the UnitTestRunner class.  Is there a way to find out which 
class called you with MethodHandles?

Heinz


From chris.hegarty at oracle.com  Wed Jun 26 13:18:32 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 26 Jun 2013 14:18:32 +0100
Subject: test with a 3rd party jar file?
In-Reply-To: <51C8E9A5.8010002@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8E9A5.8010002@oracle.com>
Message-ID: <51CAEA28.1020704@oracle.com>

The streams package recently added tests for exercising package-private 
implementation.

Top level dir contain the TEST.properties to add to the bootclasspath:

 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/

Example, individual test, whose test is in the java.util.stream package:

 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java

-Chris.

On 25/06/2013 01:51, huizhe wang wrote:
> Thanks Sean and Rob.
>
> Yes, I was told before to avoid shell scripts in tests. I'll wait till
> after your investigation to see what's the best to do in this case.
>
> -Joe
>
> On 6/24/2013 3:42 PM, Rob McKenna wrote:
>> Some interesting conversations were had lately about shell scripts
>> during Joe Darcy's recent infrastructure tech talk. In particular
>> around the idea of a "jdk.testing" package to provide libraries that
>> would help with the types of operations seen in shell scripts. I'm
>> really hoping to spend some time on this myself over the coming weeks.
>> (in an effort to at least understand why we need shell scripts and
>> whether we could do something else instead)
>>
>> In any case it should be possible to simply replace the script with a
>> java program that does the same thing. That would require fiddling
>> with Process however, and its debatable as to whether that would
>> result in fewer test failures. (shell scripts counting for a
>> proportionally large number of those failures) JSR199 might help to
>> reduce the amount of ProcessBuilders required in this instance.
>>
>>     -Rob


From xuelei.fan at oracle.com  Wed Jun 26 13:35:18 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 26 Jun 2013 13:35:18 +0000
Subject: hg: jdk8/tl/jdk: 8017049: rename property
	jdk.tls.rejectClientInitializedRenego
Message-ID: <20130626133543.3573C4854C@hg.openjdk.java.net>

Changeset: 0822bcddbd4f
Author:    xuelei
Date:      2013-06-26 06:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0822bcddbd4f

8017049: rename property jdk.tls.rejectClientInitializedRenego
Reviewed-by: vinnie, wetmore, mullan

! src/share/classes/sun/security/ssl/Handshaker.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NoImpactServerRenego.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/RejectClientRenego.java



From eric.mccorkle at oracle.com  Wed Jun 26 14:26:57 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 26 Jun 2013 10:26:57 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9F600.4020700@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9EF05.8000803@oracle.com> <51C9F34E.9000403@oracle.com>
	<51C9F600.4020700@oracle.com>
Message-ID: <51CAFA31.6000605@oracle.com>

That would be preferable to modifying the test, I think.

At this point, consider my proposed fix withdrawn, and someone should
push a change to add this test to ProblemList.txt in the immediate term.

On 06/25/13 15:56, Chris Hegarty wrote:
> On 06/25/2013 08:45 PM, Xueming Shen wrote:
>> The proposed change for 8015666 is supposed to stop this test failure.
>> But as I said
>> last time that it may take a while for it to get into the repo. I will
>> start the CCC process
>> shortly, if there is no objection.
> 
> There is no problem here. If 8015666 will resolve the test failure, then
> we can simply use 8016760 to add the test to the ProblemList.txt. It can
> then be removed along with the other changes for 8015666.
> 
> -Chris.
> 
> 
>>
>> -Sherman
>>
>> On 06/25/2013 12:27 PM, Eric McCorkle wrote:
>>> Does the fix for 8015666 stop the error from happening?  If so, then
>>> I'll withdraw this RFR.
>>>
>>> On 06/25/13 13:50, Xueming Shen wrote:
>>>> This is fine to be a workaround for the test case for now. It probably
>>>> will need to be
>>>> undo-ed after the propose change for #8015666 get integrated.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>>
>>>> The proposal for #8015666 is to keep the "existing" behavior of
>>>> ZipEntry.getTime()
>>>> to return a LastModifiedTime converted from the zip entry's
>>>> ms-dos-formatted date/time
>>>> field by using the "default" timezone. A new pair
>>>> ZipEntry.get/setLastModifiedTime()
>>>> will be added to access the "real" UTC time stored in the zip entry, if
>>>> presents.
>>>>
>>>> The API doc will be updated accordingly as well to explicitly explain
>>>> the source of the
>>>> date/time and the its timezone sensitive conversion.
>>>>
>>>> -Sherman
>>>>
>>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this simple patch which updates regression test
>>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>>
>>>>> Please note that this patch is intended to address the test failures,
>>>>> and that I will be immediately opening a new bug to investigate and
>>>>> address deeper issues, and also to properly document the API.
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>>
>>>>> The bug report is here:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>>
>>>>> Thanks,
>>>>> Eric
>>

From xueming.shen at oracle.com  Wed Jun 26 14:51:06 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 26 Jun 2013 07:51:06 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51CAFA31.6000605@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51C9EF05.8000803@oracle.com> <51C9F34E.9000403@oracle.com>
	<51C9F600.4020700@oracle.com> <51CAFA31.6000605@oracle.com>
Message-ID: <51CAFFDA.2040805@oracle.com>


I will add this into ProblemList.txt when I come in.

On 6/26/13 7:26 AM, Eric McCorkle wrote:
> That would be preferable to modifying the test, I think.
>
> At this point, consider my proposed fix withdrawn, and someone should
> push a change to add this test to ProblemList.txt in the immediate term.
>
> On 06/25/13 15:56, Chris Hegarty wrote:
>> On 06/25/2013 08:45 PM, Xueming Shen wrote:
>>> The proposed change for 8015666 is supposed to stop this test failure.
>>> But as I said
>>> last time that it may take a while for it to get into the repo. I will
>>> start the CCC process
>>> shortly, if there is no objection.
>> There is no problem here. If 8015666 will resolve the test failure, then
>> we can simply use 8016760 to add the test to the ProblemList.txt. It can
>> then be removed along with the other changes for 8015666.
>>
>> -Chris.
>>
>>
>>> -Sherman
>>>
>>> On 06/25/2013 12:27 PM, Eric McCorkle wrote:
>>>> Does the fix for 8015666 stop the error from happening?  If so, then
>>>> I'll withdraw this RFR.
>>>>
>>>> On 06/25/13 13:50, Xueming Shen wrote:
>>>>> This is fine to be a workaround for the test case for now. It probably
>>>>> will need to be
>>>>> undo-ed after the propose change for #8015666 get integrated.
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>>>
>>>>> The proposal for #8015666 is to keep the "existing" behavior of
>>>>> ZipEntry.getTime()
>>>>> to return a LastModifiedTime converted from the zip entry's
>>>>> ms-dos-formatted date/time
>>>>> field by using the "default" timezone. A new pair
>>>>> ZipEntry.get/setLastModifiedTime()
>>>>> will be added to access the "real" UTC time stored in the zip entry, if
>>>>> presents.
>>>>>
>>>>> The API doc will be updated accordingly as well to explicitly explain
>>>>> the source of the
>>>>> date/time and the its timezone sensitive conversion.
>>>>>
>>>>> -Sherman
>>>>>
>>>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this simple patch which updates regression test
>>>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>>>
>>>>>> Please note that this patch is intended to address the test failures,
>>>>>> and that I will be immediately opening a new bug to investigate and
>>>>>> address deeper issues, and also to properly document the API.
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>>>
>>>>>> The bug report is here:
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>>>
>>>>>> Thanks,
>>>>>> Eric



From chris.hegarty at oracle.com  Wed Jun 26 14:33:28 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 26 Jun 2013 14:33:28 +0000
Subject: hg: jdk8/tl/jdk: 8012647: Add Arrays.parallelPrefix (prefix sum, scan,
	cumulative sum)
Message-ID: <20130626143351.0DFAD4854F@hg.openjdk.java.net>

Changeset: e83cdd58f1cf
Author:    chegar
Date:      2013-06-26 15:30 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83cdd58f1cf

8012647: Add Arrays.parallelPrefix (prefix sum, scan, cumulative sum)
Reviewed-by: chegar, alanb, psandoz
Contributed-by: Doug Lea 
    , Tristan Yan , Chris Hegarty 

+ src/share/classes/java/util/ArrayPrefixHelpers.java
! src/share/classes/java/util/Arrays.java
+ test/java/util/Arrays/ParallelPrefix.java



From robert.field at oracle.com  Wed Jun 26 15:05:31 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 26 Jun 2013 15:05:31 +0000
Subject: hg: jdk8/tl/jdk: 8016761: Lambda metafactory - incorrect type
	conversion of constructor method handle
Message-ID: <20130626150554.74E1148551@hg.openjdk.java.net>

Changeset: 71059bca036a
Author:    rfield
Date:      2013-06-26 07:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71059bca036a

8016761: Lambda metafactory - incorrect type conversion of constructor method handle
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaConstructorMethodHandleUnbox.java



From joe.darcy at oracle.com  Wed Jun 26 16:37:46 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 26 Jun 2013 09:37:46 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: 
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
	
Message-ID: <51CB18DA.5010402@oracle.com>


On 6/25/2013 9:07 AM, Brian Burkhalter wrote:
> On Jun 24, 2013, at 9:25 PM, Joe Darcy wrote:
>
>>> "Requires the output to be padded with leading zeros to the minimum field width following any sign or radix indicator except when converting NaN or infinity. If the width is not provided, then a MissingFormatWidthException will be thrown."
>>>
>>> Comments?
>>>
>> As a point of comparison, how does the C specification of printf and how do C implementations handle this combination?
> To be certain, which combination precisely do you intend?
>

Specifically, I was referred to how C handles "%0.4f\n".

-Joe



From scolebourne at joda.org  Wed Jun 26 16:47:51 2013
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 26 Jun 2013 17:47:51 +0100
Subject: Point lambdaification of List/Set/Map
In-Reply-To: 
References: 
Message-ID: 

Sending this on to core-libs-dev to try to get a response ;-)
Stephen

On 24 June 2013 16:14, Stephen Colebourne  wrote:
> One point lambdaification that I haven't seen mentioned is addition
> static factory methods for the main collection interfaces. (Strictly,
> this proposal is not point lambdaification as it does not involve
> lambdas, but it is very much in the same area).
>
> I propose adding these static methods:
> Collection.empty()
> Collection.of(T...)
> List.empty()
> List.of(T...)
> Set.empty()
> Set.of(T...)
> Map.empty()
> Map.of(Entry...)
> Map.Entry.of(K, V)
>
> Each of these methods would return immutable implementations.
> There is a case for extending the methods to Iterator and other
> collection types, however these are the most important.
> These follow the designs of Stream static methods IIRC.
>
> This library change would remove much of the requirement for the
> "collection literals" change discussed in Project Coin.
>
> Implementation would ideally be via new dedicated immutable classes,
> however space could be saved by simply reusing the existing classes.
>
> Is this something we could fit in? (Is resourcing the problem, or the idea?)
>
> thanks
> Stephen


From brian.burkhalter at oracle.com  Wed Jun 26 17:31:28 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jun 2013 10:31:28 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <51CB18DA.5010402@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
	
	<51CB18DA.5010402@oracle.com>
Message-ID: <9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>


On Jun 26, 2013, at 9:37 AM, Joe Darcy wrote:

> Specifically, I was referred to how C handles "%0.4f\n".

On 6/24/2013 12:56 PM, Brian Burkhalter wrote:
> 
> By way of comparison, this C code
> 
>     printf("%1.4f\n", 56789.456789F);
>     printf("%0.4f\n", 56789.456789F);
> 
> prints this output
> 
> 56789.4570
> 56789.4570
   ^ ^ ^ ^ ^ ^ ^ ^
Like this.

It looks like it interprets the "0" as zero width, ignoring it as a flag. This appears contrary to the description of width in [1]:

"A leading zero in the width value is interpreted as the zero-padding flag mentioned above [?]."

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/Printf#Format_placeholders

From brian.burkhalter at oracle.com  Wed Jun 26 18:00:40 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jun 2013 11:00:40 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
	
	<51CB18DA.5010402@oracle.com>
	<9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>
Message-ID: 

For further comparison, the man page for PRINTF(1) on Mac OS 10.7.5 states

     Field Width:
             An optional digit string specifying a field width; if the output
             string has fewer characters than the field width it will be
             blank-padded on the left (or right, if the left-adjustment indi-
             cator has been given) to make up the field width (note that a
             leading zero is a flag, but an embedded zero is part of a field
             width);

and that for printf(3) on Ubuntu 12.04

   The field width
       An  optional decimal digit string (with nonzero first digit) specifying
       a minimum field width.  If the converted  value  has  fewer  characters
       than  the  field  width,  it will be padded with spaces on the left (or
       right, if the left-adjustment flag has been given).  Instead of a deci?
       mal  digit  string one may write "*" or "*m$" (for some decimal integer
       m) to specify that the field width is given in the next argument, or in
       the m-th argument, respectively, which must be of type int.  A negative
       field width is taken as a '-' flag followed by a positive field  width.
       In  no case does a nonexistent or small field width cause truncation of
       a field; if the result of a conversion is wider than the  field  width,
       the field is expanded to contain the conversion result.

Ubuntu Linux and Mac OS X show the same behavior for

    printf("%0.4f\n", 56789.456789F);

which is to print

56789.4570

This looks as if the default width is taken to be zero. Adopting this behavior for Formatter however would look to be in violation of its specification

'0'	'\u0030'	Requires the output to be padded with leading zeros to the minimum field width following any sign or radix indicator except when converting NaN or infinity. If the width is not provided, then a MissingFormatWidthException will be thrown.

On Jun 26, 2013, at 10:31 AM, Brian Burkhalter wrote:

> "A leading zero in the width value is interpreted as the zero-padding flag mentioned above [?]." [1]

[1] https://en.wikipedia.org/wiki/Printf#Format_placeholders



From brian.burkhalter at oracle.com  Wed Jun 26 18:13:18 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jun 2013 11:13:18 -0700
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
Message-ID: 

So do we have consensus on this version?

Thanks for the lively "conversation."

Brian

On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:

> Yes, like that.
> 
> -Aleksey
> 
> On 26.06.2013, at 10:53, Dmitry Nadezhin  wrote:
> 
>>> We could check for the existing cacheLine.length right before installing
>> the new one
>> 
>> Do you mean something like this ?
>> 
>> BigInteger getRadixConversionCache(int radix, int exponent) {
>> BigInteger[] cacheLine = powerCache[radix]; // volatile read
>> if (exponent < cacheLine.length)
>>    return cacheLine[exponent];
>> 
>> int oldLength = cacheLine.length;
>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>> for (int i = oldLength; i < exponent + 1; i++)
>>    cacheLine[i] = cacheLine[i - 1].square();
>> 
>> if (exponent >= powerCache[radix].length) { // volatile read again
>>   BigInteger[][] pc = Arrays.copyOf(powerCache);
>>   pc[radix] = cacheLine;
>>   powerCache = pc; // volatile write, publish
>> }
>> return cacheLine[exponent];
>> }



From naoto.sato at oracle.com  Wed Jun 26 18:21:50 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 26 Jun 2013 18:21:50 +0000
Subject: hg: jdk8/tl/jdk: 8017322: java/util/Currency/PropertiesTest.sh should
	run exclusively
Message-ID: <20130626182204.15CB648562@hg.openjdk.java.net>

Changeset: 336e5a862013
Author:    naoto
Date:      2013-06-26 11:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336e5a862013

8017322: java/util/Currency/PropertiesTest.sh should run exclusively
Reviewed-by: alanb

! test/TEST.ROOT



From eric.mccorkle at oracle.com  Wed Jun 26 18:47:49 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Wed, 26 Jun 2013 14:47:49 -0400
Subject: JDK-8016285: Add java.lang.reflect.Parameter.isNamePresent()
In-Reply-To: <51C8BA0E.7040109@oracle.com>
References: <51C4B02B.7040004@oracle.com> <51C4B47E.4060702@oracle.com>
	<51C4E010.1050603@oracle.com> <51C89C00.20604@oracle.com>
	<51C8BA0E.7040109@oracle.com>
Message-ID: <51CB3755.8020805@oracle.com>

Can I get a capital-R review on this so I can put it through?

On 06/24/13 17:28, Aleksey Shipilev wrote:
> Forgot to reply: I'm ok with webrev.01.
> 
> -Aleksey
> (rural r reviewer)
> 
> On 06/24/2013 11:20 PM, Eric McCorkle wrote:
>> Pinging this RFR.  It still needs a capital R reviewer.
>> http://cr.openjdk.java.net/~emc/8016285/
>>
>> On 06/21/13 19:21, Eric McCorkle wrote:
>>> On 06/21/13 16:15, Aleksey Shipilev wrote:
>>>> On 06/21/2013 11:57 PM, Eric McCorkle wrote:
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8016285/
>>>>
>>>> Looks generally good (but not a Reviewer).
>>>>
>>>> A few questions though:
>>>>   a) Are we em-bracing the brace-less control flow blocks?
>>>
>>> Fixed it.
>>>
>>>>   b) Should hasRealParameterData be transient?
>>>>   c) Should hasRealParameterData be volatile? (now is being implicitly
>>>> protected by $parameters volatile write/read, but it is fragile)
>>>
>>> Transient yes.  Volatile, I'd say I think not, since It's written before
>>> it's read on all possible paths, and all writes are the same value.
>>> But...  I set it volatile just to be safe from reordering problems.
>>>
>>> Webrev's been updated.
>>> http://cr.openjdk.java.net/~emc/8016285/
>>>
> 

From kumar.x.srinivasan at oracle.com  Wed Jun 26 16:58:04 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 26 Jun 2013 16:58:04 +0000
Subject: hg: jdk8/tl/langtools: 8016908: TEST_BUG: removing non-ascii
	characters causes tests to fail
Message-ID: <20130626165811.1043E4855B@hg.openjdk.java.net>

Changeset: c2d9303c3477
Author:    ksrini
Date:      2013-06-26 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c2d9303c3477

8016908: TEST_BUG: removing non-ascii characters causes tests to fail
Reviewed-by: jjg, vromero

! test/tools/javac/api/6437999/T6437999.java
- test/tools/javac/api/6437999/Utf8.java
! test/tools/javac/api/T6306137.java



From joe.darcy at oracle.com  Wed Jun 26 19:21:50 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 26 Jun 2013 12:21:50 -0700
Subject: JDK 8 code review request for java.math doclint / accessibility
	cleanup
Message-ID: <51CB3F4E.7000800@oracle.com>

Hello,

Please review the changes in the patch below; these change address the 
doclint and HTML accessibility issues in java.math.

I'll find an existing bug or if one is not present, file a new bug to 
cover this work.

Thanks,

-Joe

diff -r 336e5a862013 src/share/classes/java/math/BigDecimal.java
--- a/src/share/classes/java/math/BigDecimal.java    Wed Jun 26 11:21:01 
2013 -0700
+++ b/src/share/classes/java/math/BigDecimal.java    Wed Jun 26 12:20:28 
2013 -0700
@@ -2572,6 +2572,9 @@
       * ({@code this} * 10n).  The scale of
       * the result is {@code (this.scale() - n)}.
       *
+     * @param n the exponent power to ten to scale by
+     * @return a BigDecimal whose numerical value is equal to
+     * ({@code this} * 10n)
       * @throws ArithmeticException if the scale would be
       *         outside the range of a 32-bit integer.
       *
diff -r 336e5a862013 src/share/classes/java/math/RoundingMode.java
--- a/src/share/classes/java/math/RoundingMode.java    Wed Jun 26 
11:21:01 2013 -0700
+++ b/src/share/classes/java/math/RoundingMode.java    Wed Jun 26 
12:20:28 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -101,6 +101,7 @@
           *
           *
    Example:
           *
+         * 
           *
           *    
@@ -124,6 +125,7 @@
           *
           *
    Example:
           *
    Rounding mode UP Examples
    Input NumberInput rounded to one digit
     with {@code UP} rounding
           *
    5.5 6
    
+         * 
           *
           *    
@@ -148,6 +150,7 @@
           *
           *
    Example:
           *
    Rounding mode DOWN Examples
    Input NumberInput rounded to one digit
     with {@code DOWN} 
rounding
           *
    5.5 5
    
+         * 
           *
           *    
@@ -172,6 +175,7 @@
           *
           *
    Example:
           *
    Rounding mode CEILING Examples
    Input NumberInput rounded to one digit
     with {@code CEILING} 
rounding
           *
    5.5 6
    
+         * 
           *
           *    
@@ -198,6 +202,7 @@
           *
           *
    Example:
           *
    Rounding mode FLOOR Examples
    Input NumberInput rounded to one digit
     with {@code FLOOR} 
rounding
           *
    5.5 5
    
+         * 
           *
           *    
@@ -223,6 +228,7 @@
           *
           *
    Example:
           *
    Rounding mode HALF_UP Examples
    Input NumberInput rounded to one digit
     with {@code HALF_UP} 
rounding
           *
    5.5 6
    
+         * 
           *
           *    
@@ -255,6 +261,7 @@
           *
           *
    Example:
           *
    Rounding mode HALF_DOWN Examples
    Input NumberInput rounded to one digit
     with {@code 
HALF_DOWN} rounding
           *
    5.5 5
    
+         * 
           *
           *    
@@ -278,6 +285,7 @@
           * {@code ArithmeticException} is thrown.
           *
    Example:
           *
    Rounding mode HALF_EVEN Examples
    Input NumberInput rounded to one digit
     with {@code 
HALF_EVEN} rounding
           *
    5.5 6
    
+         * 
           *
           *    



From brian.burkhalter at oracle.com  Wed Jun 26 19:35:00 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Jun 2013 12:35:00 -0700
Subject: JDK 8 code review request for java.math doclint / accessibility
	cleanup
In-Reply-To: <51CB3F4E.7000800@oracle.com>
References: <51CB3F4E.7000800@oracle.com>
Message-ID: 

Hi Joe,

On Jun 26, 2013, at 12:21 PM, Joe Darcy wrote:

> Please review the changes in the patch below; these change address the doclint and HTML accessibility issues in java.math.

Looks good to me but I am not a Reviewer.

> I'll find an existing bug or if one is not present, file a new bug to cover this work.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7018139

Brian

From Lance.Andersen at oracle.com  Wed Jun 26 20:06:54 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Wed, 26 Jun 2013 16:06:54 -0400
Subject: JDK 8 code review request for java.math doclint / accessibility
	cleanup
In-Reply-To: <51CB3F4E.7000800@oracle.com>
References: <51CB3F4E.7000800@oracle.com>
Message-ID: <96A6161B-F94E-4E07-B838-3B8A13BB3927@oracle.com>

Hi Joe,

Looks fine

Best
Lance
On Jun 26, 2013, at 3:21 PM, Joe Darcy  wrote:

> Hello,
> 
> Please review the changes in the patch below; these change address the doclint and HTML accessibility issues in java.math.
> 
> I'll find an existing bug or if one is not present, file a new bug to cover this work.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 336e5a862013 src/share/classes/java/math/BigDecimal.java
> --- a/src/share/classes/java/math/BigDecimal.java    Wed Jun 26 11:21:01 2013 -0700
> +++ b/src/share/classes/java/math/BigDecimal.java    Wed Jun 26 12:20:28 2013 -0700
> @@ -2572,6 +2572,9 @@
>      * ({@code this} * 10n).  The scale of
>      * the result is {@code (this.scale() - n)}.
>      *
> +     * @param n the exponent power to ten to scale by
> +     * @return a BigDecimal whose numerical value is equal to
> +     * ({@code this} * 10n)
>      * @throws ArithmeticException if the scale would be
>      *         outside the range of a 32-bit integer.
>      *
> diff -r 336e5a862013 src/share/classes/java/math/RoundingMode.java
> --- a/src/share/classes/java/math/RoundingMode.java    Wed Jun 26 11:21:01 2013 -0700
> +++ b/src/share/classes/java/math/RoundingMode.java    Wed Jun 26 12:20:28 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -101,6 +101,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode UNNECESSARY Examples
    Input NumberInput rounded to one digit
     with {@code 
UNNECESSARY} rounding
           *
    5.5 throw {@code 
ArithmeticException}
    
> +         * 
>          *
>          *    
> @@ -124,6 +125,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode UP Examples
    Input NumberInput rounded to one digit
     with {@code UP} rounding
>          *
    5.5 6
    
> +         * 
>          *
>          *    
> @@ -148,6 +150,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode DOWN Examples
    Input NumberInput rounded to one digit
     with {@code DOWN} rounding
>          *
    5.5 5
    
> +         * 
>          *
>          *    
> @@ -172,6 +175,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode CEILING Examples
    Input NumberInput rounded to one digit
     with {@code CEILING} rounding
>          *
    5.5 6
    
> +         * 
>          *
>          *    
> @@ -198,6 +202,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode FLOOR Examples
    Input NumberInput rounded to one digit
     with {@code FLOOR} rounding
>          *
    5.5 5
    
> +         * 
>          *
>          *    
> @@ -223,6 +228,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode HALF_UP Examples
    Input NumberInput rounded to one digit
     with {@code HALF_UP} rounding
>          *
    5.5 6
    
> +         * 
>          *
>          *    
> @@ -255,6 +261,7 @@
>          *
>          *
    Example:
>          *
    Rounding mode HALF_DOWN Examples
    Input NumberInput rounded to one digit
     with {@code HALF_DOWN} rounding
>          *
    5.5 5
    
> +         * 
>          *
>          *    
> @@ -278,6 +285,7 @@
>          * {@code ArithmeticException} is thrown.
>          *
    Example:
>          *
    Rounding mode HALF_EVEN Examples
    Input NumberInput rounded to one digit
     with {@code HALF_EVEN} rounding
>          *
    5.5 6
    
> +         * 
>          *
>          *    
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From joe.darcy at oracle.com  Wed Jun 26 20:24:31 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 26 Jun 2013 20:24:31 +0000
Subject: hg: jdk8/tl/jdk: 7018139: Fix HTML accessibility and doclint issues
	in java.math
Message-ID: <20130626202504.36FF848576@hg.openjdk.java.net>

Changeset: 1fda8fa7ae97
Author:    darcy
Date:      2013-06-26 13:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fda8fa7ae97

7018139: Fix HTML accessibility and doclint issues in java.math
Reviewed-by: lancea, bpb

! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/RoundingMode.java



From jonathan.gibbons at oracle.com  Thu Jun 27 01:04:31 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 27 Jun 2013 01:04:31 +0000
Subject: hg: jdk8/tl/langtools: 8014137: Update
	test/tools/javac/literals/UnderscoreLiterals to add testcases
	with min/max values
Message-ID: <20130627010436.E3A7F48583@hg.openjdk.java.net>

Changeset: 3b2e10524627
Author:    jjg
Date:      2013-06-26 18:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3b2e10524627

8014137: Update test/tools/javac/literals/UnderscoreLiterals to add testcases with min/max values
Reviewed-by: jjg, darcy
Contributed-by: matherey.nunez at oracle.com

! test/tools/javac/literals/UnderscoreLiterals.java



From joe.darcy at oracle.com  Thu Jun 27 01:23:04 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 26 Jun 2013 18:23:04 -0700
Subject: JDK 8 request for review: remove final doclint warnings from
	java.util.zip
Message-ID: <51CB93F8.2030606@oracle.com>

Hello,

The java.util.zip package has a few remaining doctlint warnings; the 
patch below removes them.

Thanks,

-Joe

diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Deflater.java
--- a/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
13:24:13 2013 -0700
+++ b/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
18:22:45 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -461,7 +461,7 @@
      }

      /**
-     * Returns the total number of uncompressed bytes input so far.
    
+     * Returns the total number of uncompressed bytes input so far.
       *
       * @return the total (non-negative) number of uncompressed bytes 
input so far
       * @since 1.5
@@ -487,7 +487,7 @@
      }

      /**
-     * Returns the total number of compressed bytes output so far.
    
+     * Returns the total number of compressed bytes output so far.
       *
       * @return the total (non-negative) number of compressed bytes 
output so far
       * @since 1.5
diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Inflater.java
--- a/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
13:24:13 2013 -0700
+++ b/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
18:22:45 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -305,7 +305,7 @@
      }

      /**
-     * Returns the total number of compressed bytes input so far.
    
+     * Returns the total number of compressed bytes input so far.
       *
       * @return the total (non-negative) number of compressed bytes 
input so far
       * @since 1.5
@@ -331,7 +331,7 @@
      }

      /**
-     * Returns the total number of uncompressed bytes output so far.
    
+     * Returns the total number of uncompressed bytes output so far.
       *
       * @return the total (non-negative) number of uncompressed bytes 
output so far
       * @since 1.5



From joe.darcy at oracle.com  Thu Jun 27 02:11:29 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 02:11:29 +0000
Subject: hg: jdk8/tl/jdk: 8019223: Fix doclint warnings in java.rmi.server
Message-ID: <20130627021154.13AE048591@hg.openjdk.java.net>

Changeset: a5aa57eb85b6
Author:    darcy
Date:      2013-06-26 19:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5aa57eb85b6

8019223: Fix doclint warnings in java.rmi.server
Reviewed-by: smarks

! src/share/classes/java/rmi/server/RMIClassLoader.java



From bhavesh.x.patel at oracle.com  Thu Jun 27 03:43:35 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 27 Jun 2013 03:43:35 +0000
Subject: hg: jdk8/tl/langtools: 8014017: extra space in javadoc class heading
Message-ID: <20130627034337.CA2DE48596@hg.openjdk.java.net>

Changeset: 27bd6a2302f6
Author:    bpatel
Date:      2013-06-26 20:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27bd6a2302f6

8014017: extra space in javadoc class heading
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java



From bhavesh.x.patel at oracle.com  Thu Jun 27 03:46:23 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 27 Jun 2013 03:46:23 +0000
Subject: hg: jdk8/tl/langtools: 8013738: Two javadoc tests have bug 0000000
Message-ID: <20130627034626.B473648597@hg.openjdk.java.net>

Changeset: 36e8bc1907a2
Author:    bpatel
Date:      2013-06-26 20:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e8bc1907a2

8013738: Two javadoc tests have bug 0000000
Reviewed-by: jjg

! test/com/sun/javadoc/testNestedInlineTag/TestNestedInlineTag.java
! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java



From bhavesh.x.patel at oracle.com  Thu Jun 27 03:39:41 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 27 Jun 2013 03:39:41 +0000
Subject: hg: jdk8/tl/langtools: 8007338: Method grouping tab line-folding
Message-ID: <20130627033947.CCC5A48594@hg.openjdk.java.net>

Changeset: 4fe5aab73bb2
Author:    bpatel
Date:      2013-06-26 20:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4fe5aab73bb2

8007338: Method grouping tab line-folding
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java



From bradford.wetmore at oracle.com  Thu Jun 27 04:37:59 2013
From: bradford.wetmore at oracle.com (Brad Wetmore)
Date: Wed, 26 Jun 2013 21:37:59 -0700
Subject: Review Request: JDK-8019227: JDK-8010325 broke the old build
Message-ID: <51CBC1A7.5020206@oracle.com>

Brent/Alan/Mike,

Hashing.java was removed from the JDK workspace, but was not removed 
from the old java/java/FILES_java.gmk.  Things that still depend on the 
old build (JCE/deploy) are currently broken.

http://cr.openjdk.java.net/~wetmore/8019227/webrev.00/

Brad

P.S. I'm very aware that we need to move off the old build soon and am 
getting closer to finally working on it with Erik, and that the old 
build isn't complete.  But it's complete enough for the JCE 
dependencies.  Unfortunately, this isn't a simple transition 
(JDK-8006350), and this is a quick fix to get the JCE bits built.




From xueming.shen at oracle.com  Thu Jun 27 04:48:06 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 26 Jun 2013 21:48:06 -0700
Subject: JDK 8 request for review: remove final doclint warnings from
	java.util.zip
In-Reply-To: <51CB93F8.2030606@oracle.com>
References: <51CB93F8.2030606@oracle.com>
Message-ID: <51CBC406.5040703@oracle.com>

looks fine. thanks for taking care of this.

-Sherman

On 6/26/13 6:23 PM, Joe Darcy wrote:
> Hello,
>
> The java.util.zip package has a few remaining doctlint warnings; the 
> patch below removes them.
>
> Thanks,
>
> -Joe
>
> diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Deflater.java
> --- a/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
> 13:24:13 2013 -0700
> +++ b/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
> 18:22:45 2013 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -461,7 +461,7 @@
>      }
>
>      /**
> -     * Returns the total number of uncompressed bytes input so far.
    
> +     * Returns the total number of uncompressed bytes input so far.
>       *
>       * @return the total (non-negative) number of uncompressed bytes 
> input so far
>       * @since 1.5
> @@ -487,7 +487,7 @@
>      }
>
>      /**
> -     * Returns the total number of compressed bytes output so far.
    
> +     * Returns the total number of compressed bytes output so far.
>       *
>       * @return the total (non-negative) number of compressed bytes 
> output so far
>       * @since 1.5
> diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Inflater.java
> --- a/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
> 13:24:13 2013 -0700
> +++ b/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
> 18:22:45 2013 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -305,7 +305,7 @@
>      }
>
>      /**
> -     * Returns the total number of compressed bytes input so far.
    
> +     * Returns the total number of compressed bytes input so far.
>       *
>       * @return the total (non-negative) number of compressed bytes 
> input so far
>       * @since 1.5
> @@ -331,7 +331,7 @@
>      }
>
>      /**
> -     * Returns the total number of uncompressed bytes output so far.
    
> +     * Returns the total number of uncompressed bytes output so far.
>       *
>       * @return the total (non-negative) number of uncompressed bytes 
> output so far
>       * @since 1.5
>



From mandy.chung at oracle.com  Thu Jun 27 04:48:14 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 26 Jun 2013 21:48:14 -0700
Subject: JDK 8 request for review: remove final doclint warnings from
	java.util.zip
In-Reply-To: <51CB93F8.2030606@oracle.com>
References: <51CB93F8.2030606@oracle.com>
Message-ID: <51CBC40E.6050903@oracle.com>

Looks fine to me.

Mandy

On 6/26/2013 6:23 PM, Joe Darcy wrote:
> Hello,
>
> The java.util.zip package has a few remaining doctlint warnings; the 
> patch below removes them.
>
> Thanks,
>
> -Joe
>
> diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Deflater.java
> --- a/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
> 13:24:13 2013 -0700
> +++ b/src/share/classes/java/util/zip/Deflater.java    Wed Jun 26 
> 18:22:45 2013 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -461,7 +461,7 @@
>      }
>
>      /**
> -     * Returns the total number of uncompressed bytes input so far.
    
> +     * Returns the total number of uncompressed bytes input so far.
>       *
>       * @return the total (non-negative) number of uncompressed bytes 
> input so far
>       * @since 1.5
> @@ -487,7 +487,7 @@
>      }
>
>      /**
> -     * Returns the total number of compressed bytes output so far.
    
> +     * Returns the total number of compressed bytes output so far.
>       *
>       * @return the total (non-negative) number of compressed bytes 
> output so far
>       * @since 1.5
> diff -r 1fda8fa7ae97 src/share/classes/java/util/zip/Inflater.java
> --- a/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
> 13:24:13 2013 -0700
> +++ b/src/share/classes/java/util/zip/Inflater.java    Wed Jun 26 
> 18:22:45 2013 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -305,7 +305,7 @@
>      }
>
>      /**
> -     * Returns the total number of compressed bytes input so far.
    
> +     * Returns the total number of compressed bytes input so far.
>       *
>       * @return the total (non-negative) number of compressed bytes 
> input so far
>       * @since 1.5
> @@ -331,7 +331,7 @@
>      }
>
>      /**
> -     * Returns the total number of uncompressed bytes output so far.
    
> +     * Returns the total number of uncompressed bytes output so far.
>       *
>       * @return the total (non-negative) number of uncompressed bytes 
> output so far
>       * @since 1.5
>



From eric.mccorkle at oracle.com  Thu Jun 27 04:39:54 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 27 Jun 2013 04:39:54 +0000
Subject: hg: jdk8/tl/langtools: 8014230: Compilation incorrectly succeeds with
	inner class constructor with 254 parameters
Message-ID: <20130627043957.C59134859B@hg.openjdk.java.net>

Changeset: c674b396827c
Author:    emc
Date:      2013-06-27 00:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c674b396827c

8014230: Compilation incorrectly succeeds with inner class constructor with 254 parameters
Summary: The compiler does not account fr extra parameters due to inner this parameters
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/main/Main.java
+ test/tools/javac/limits/NestedClassConstructorArgs.java
+ test/tools/javac/limits/NestedClassMethodArgs.java
- test/tools/javac/limits/NumArgs1.java
- test/tools/javac/limits/NumArgs2.java
- test/tools/javac/limits/NumArgs3.java
- test/tools/javac/limits/NumArgs4.java
+ test/tools/javac/limits/NumArgsTest.java
+ test/tools/javac/limits/StaticNestedClassConstructorArgs.java
+ test/tools/javac/limits/TopLevelClassConstructorArgs.java
+ test/tools/javac/limits/TopLevelClassMethodArgs.java
+ test/tools/javac/limits/TopLevelClassStaticMethodArgs.java



From joe.darcy at oracle.com  Thu Jun 27 05:12:20 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 05:12:20 +0000
Subject: hg: jdk8/tl/jdk: 8019228: Fix doclint issues in java.util.zip
Message-ID: <20130627051241.8973A4859D@hg.openjdk.java.net>

Changeset: ac65905883a7
Author:    darcy
Date:      2013-06-26 22:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac65905883a7

8019228: Fix doclint issues in java.util.zip
Reviewed-by: sherman, mchung

! src/share/classes/java/util/zip/Deflater.java
! src/share/classes/java/util/zip/Inflater.java



From david.dehaven at oracle.com  Thu Jun 27 05:55:39 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 26 Jun 2013 22:55:39 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
	
	<51CB18DA.5010402@oracle.com>
	<9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>
Message-ID: <518390B2-C0E1-43A9-8BD8-68211414C633@oracle.com>


>> Specifically, I was referred to how C handles "%0.4f\n".

No width, decimal truncated (rounded? floored? I forgot which it is) to four digits.

-DrD-


>>    printf("%0.4f\n", 56789.456789F);
...
>> 56789.4570
>   ^ ^ ^ ^ ^ ^ ^ ^
...
> "A leading zero in the width value is interpreted as the zero-padding flag mentioned above [?]."

Only if there's a valid width following, which there isn't in the case above. Try "%016.4" with the above test. Note that the width is the *full* width of the entire field, including decimal point and following digits.

printf("%016.4f\n", 56789.456789F);
printf("%0.4f\n", 56789.456789F);

Produces:
00000056789.4570
56789.4570

-DrD-



From Alan.Bateman at oracle.com  Thu Jun 27 06:13:39 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Jun 2013 07:13:39 +0100
Subject: Review Request: JDK-8019227: JDK-8010325 broke the old build
In-Reply-To: <51CBC1A7.5020206@oracle.com>
References: <51CBC1A7.5020206@oracle.com>
Message-ID: <51CBD813.6080807@oracle.com>

On 27/06/2013 05:37, Brad Wetmore wrote:
> Brent/Alan/Mike,
>
> Hashing.java was removed from the JDK workspace, but was not removed 
> from the old java/java/FILES_java.gmk.  Things that still depend on 
> the old build (JCE/deploy) are currently broken.
>
> http://cr.openjdk.java.net/~wetmore/8019227/webrev.00/
>
> Brad
>
> P.S. I'm very aware that we need to move off the old build soon and am 
> getting closer to finally working on it with Erik, and that the old 
> build isn't complete.  But it's complete enough for the JCE 
> dependencies.  Unfortunately, this isn't a simple transition 
> (JDK-8006350), and this is a quick fix to get the JCE bits built.

The old build has not produced usable bits for several months, it may 
not have been failing but if you look closely (or run the tests) then 
you'll see that there are several things missing. On build-dev then 
you'll probably have seen a mail or two from me where I was trying to 
encourage the build group to set a date to finally retire and remove the 
old build - this is because the old build is just a tax on every change 
that needs to touch the build.

Anyway, the change looks okay but I strongly encourage you to put in the 
time to resolve the usability or others ssues that arise when working on 
JCE.

-Alan


From peter.levart at gmail.com  Thu Jun 27 06:37:28 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 27 Jun 2013 08:37:28 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: 
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
Message-ID: <51CBDDA8.4000107@gmail.com>

Hi,

This version seems correct. Maybe just replace double volatile read at 
length re-check with a single one:


     private static BigInteger getRadixConversionCache(int radix, int 
exponent) {
         BigInteger[] cacheLine = powerCache[radix]; // volatile read
         if (exponent < cacheLine.length)
             return cacheLine[exponent];

         int oldLength = cacheLine.length;
         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
         for (int i = oldLength; i <= exponent; i++)
             cacheLine[i] = cacheLine[i - 1].pow(2);

         BigInteger[][] pc = powerCache; // volatile read again
         if (exponent >= pc[radix].length) {
             pc = pc.clone();
             pc[radix] = cacheLine;
             powerCache = pc; // volatile write, publish
         }
         return cacheLine[exponent];
     }


I like this, since it tries to avoid overwriting larger cacheLines with 
smaller ones when unexistent exponents are requested concurrently for 
same radix. This is good, since computation for larger exponents takes 
quadratically longer time (as Alan Eliasen points out) and possibility 
of concurrent threads stomping on each other increases. Re-reading and 
cloning powerCache reference at end of computation also takes care of 
cacheLines for other radixes that might have expanded while the 
computation was taking place. So the only overhead remaining is when 
concurrent threads are uselessly computing same results at same time. To 
avoid this, locking and waiting would have to be introduced which would 
complicate things.

Regards, Peter

On 06/26/2013 08:13 PM, Brian Burkhalter wrote:
> So do we have consensus on this version?
>
> Thanks for the lively "conversation."
>
> Brian
>
> On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:
>
>> Yes, like that.
>>
>> -Aleksey
>>
>> On 26.06.2013, at 10:53, Dmitry Nadezhin  wrote:
>>
>>>> We could check for the existing cacheLine.length right before installing
>>> the new one
>>>
>>> Do you mean something like this ?
>>>
>>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>> BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>> if (exponent < cacheLine.length)
>>>     return cacheLine[exponent];
>>>
>>> int oldLength = cacheLine.length;
>>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>> for (int i = oldLength; i < exponent + 1; i++)
>>>     cacheLine[i] = cacheLine[i - 1].square();
>>>
>>> if (exponent >= powerCache[radix].length) { // volatile read again
>>>    BigInteger[][] pc = Arrays.copyOf(powerCache);
>>>    pc[radix] = cacheLine;
>>>    powerCache = pc; // volatile write, publish
>>> }
>>> return cacheLine[exponent];
>>> }



From peter.levart at gmail.com  Thu Jun 27 07:27:52 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 27 Jun 2013 09:27:52 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CBDDA8.4000107@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
	<51CBDDA8.4000107@gmail.com>
Message-ID: <51CBE978.500@gmail.com>

On 06/27/2013 08:37 AM, Peter Levart wrote:
> Hi,
>
> This version seems correct. Maybe just replace double volatile read at 
> length re-check with a single one:
>
>
>     private static BigInteger getRadixConversionCache(int radix, int 
> exponent) {
>         BigInteger[] cacheLine = powerCache[radix]; // volatile read
>         if (exponent < cacheLine.length)
>             return cacheLine[exponent];
>
>         int oldLength = cacheLine.length;
>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>         for (int i = oldLength; i <= exponent; i++)
>             cacheLine[i] = cacheLine[i - 1].pow(2);
>
>         BigInteger[][] pc = powerCache; // volatile read again
>         if (exponent >= pc[radix].length) {
>             pc = pc.clone();
>             pc[radix] = cacheLine;
>             powerCache = pc; // volatile write, publish
>         }
>         return cacheLine[exponent];
>     }
>
>
> I like this, since it tries to avoid overwriting larger cacheLines 
> with smaller ones when unexistent exponents are requested concurrently 
> for same radix. This is good, since computation for larger exponents 
> takes quadratically longer time (as Alan Eliasen points out) and 
> possibility of concurrent threads stomping on each other increases. 
> Re-reading and cloning powerCache reference at end of computation also 
> takes care of cacheLines for other radixes that might have expanded 
> while the computation was taking place. So the only overhead remaining 
> is when concurrent threads are uselessly computing same results at 
> same time. To avoid this, locking and waiting would have to be 
> introduced which would *complicate things*.
>
> Regards, Peter

On the other hand, it doesn't complicate thing too much. So if this 
extra CPU time proves to be a problem, here's a variation of above code 
which prevents multiple threads from calculating the same result at the 
same time, by serializing computation with precise granularity:

     private static class Node {
         final BigInteger value;
         Node next;
         Node(BigInteger value) { this.value = value; }
     }

     private static volatile Node[][] powerCache;

     static {
         powerCache = new Node[Character.MAX_RADIX + 1][];
         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; i++) {
             powerCache[i] = new Node[]{new Node(BigInteger.valueOf(i))};
         }
     }

     private static BigInteger getRadixConversionCache(int radix, int 
exponent) {
         Node[] cacheLine = powerCache[radix]; // volatile read
         if (exponent < cacheLine.length)
             return cacheLine[exponent].value;

         int oldLength = cacheLine.length;
         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
         Node prevNode = cacheLine[oldLength - 1];
         for (int i = oldLength; i <= exponent; i++) {
             Node node;
             synchronized (prevNode) {
                 node = prevNode.next;
                 if (node == null) {
                     node = new Node(prevNode.value.pow(2));
                     prevNode.next = node;
                 }
             }
             cacheLine[i] = prevNode = node;
         }

         Node[][] pc = powerCache; // volatile read again
         if (exponent >= pc[radix].length) {
             pc = pc.clone();
             pc[radix] = cacheLine;
             powerCache = pc; // volatile write, publish
         }
         return cacheLine[exponent].value;
     }


This variation differs only in a subtelty. It wraps each BigInteger with 
a Node, which has a link to next node in chain. Computation of next node 
is serailized using previous node as a lock. So although Nodes can end 
up in several arrays (which are used as index for quick access), there 
is only a single growing chain of Nodes per radix and each Node is 
computed by single thread.

Regards, Peter

>
> On 06/26/2013 08:13 PM, Brian Burkhalter wrote:
>> So do we have consensus on this version?
>>
>> Thanks for the lively "conversation."
>>
>> Brian
>>
>> On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:
>>
>>> Yes, like that.
>>>
>>> -Aleksey
>>>
>>> On 26.06.2013, at 10:53, Dmitry Nadezhin  
>>> wrote:
>>>
>>>>> We could check for the existing cacheLine.length right before 
>>>>> installing
>>>> the new one
>>>>
>>>> Do you mean something like this ?
>>>>
>>>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>>> BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>>> if (exponent < cacheLine.length)
>>>>     return cacheLine[exponent];
>>>>
>>>> int oldLength = cacheLine.length;
>>>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>>> for (int i = oldLength; i < exponent + 1; i++)
>>>>     cacheLine[i] = cacheLine[i - 1].square();
>>>>
>>>> if (exponent >= powerCache[radix].length) { // volatile read again
>>>>    BigInteger[][] pc = Arrays.copyOf(powerCache);
>>>>    pc[radix] = cacheLine;
>>>>    powerCache = pc; // volatile write, publish
>>>> }
>>>> return cacheLine[exponent];
>>>> }
>



From huizhe.wang at oracle.com  Thu Jun 27 07:50:05 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 27 Jun 2013 00:50:05 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <51CAEA28.1020704@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8E9A5.8010002@oracle.com>
	<51CAEA28.1020704@oracle.com>
Message-ID: <51CBEEAD.3050308@oracle.com>

Hi Chris,

Thanks for the information!  I'll give it a try.

On 6/26/2013 6:18 AM, Chris Hegarty wrote:
> The streams package recently added tests for exercising 
> package-private implementation.
>
> Top level dir contain the TEST.properties to add to the bootclasspath:

Do you mean TEST.properties need to be in the top level directory (e.g. 
javax/xml/jaxp), can it be put anywhere that contains a block of tests?

In my particular case, I only want to run a single test with the jar 
file on the bootclasspath.

Thanks,
Joe

>
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/ 
>
>
> Example, individual test, whose test is in the java.util.stream package:
>
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java 
>
>
> -Chris.
>
> On 25/06/2013 01:51, huizhe wang wrote:
>> Thanks Sean and Rob.
>>
>> Yes, I was told before to avoid shell scripts in tests. I'll wait till
>> after your investigation to see what's the best to do in this case.
>>
>> -Joe
>>
>> On 6/24/2013 3:42 PM, Rob McKenna wrote:
>>> Some interesting conversations were had lately about shell scripts
>>> during Joe Darcy's recent infrastructure tech talk. In particular
>>> around the idea of a "jdk.testing" package to provide libraries that
>>> would help with the types of operations seen in shell scripts. I'm
>>> really hoping to spend some time on this myself over the coming weeks.
>>> (in an effort to at least understand why we need shell scripts and
>>> whether we could do something else instead)
>>>
>>> In any case it should be possible to simply replace the script with a
>>> java program that does the same thing. That would require fiddling
>>> with Process however, and its debatable as to whether that would
>>> result in fewer test failures. (shell scripts counting for a
>>> proportionally large number of those failures) JSR199 might help to
>>> reduce the amount of ProcessBuilders required in this instance.
>>>
>>>     -Rob



From zhangshj at linux.vnet.ibm.com  Thu Jun 27 08:02:09 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Thu, 27 Jun 2013 16:02:09 +0800
Subject: Question on HashMap change in 8011200
Message-ID: <51CBF181.1020301@linux.vnet.ibm.com>

Hi,

There are some isEmpty() check added into get/remove methods since 
8011200 to return directly if HashMap is empty. However isEmpty is a 
non-final public method which can be overridden by subclass. If the 
subclass defines isEmpty differently from HashMap, it would cause 
problem while getting or removing elements.

For example, here is a simple test case, the subclass of HashMap always 
has at least one key value pair so isEmpty will never be false.

///////////////////////////////////////////////////////////////////////////////

import java.util.HashMap;


public class HashMapTest {
     public static class NotEmptyHashMap extends HashMap {
         private K alwaysExistingKey;
         private V alwaysExistingValue;

         @Override
         public V get(Object key) {
             if (key == alwaysExistingKey) {
                 return alwaysExistingValue;
             }
             return super.get(key);
         }

         @Override
         public int size() {
             return super.size() + 1;
         }

         @Override
         public boolean isEmpty() {
             return size() == 0;
         }
     }

     public static void main(String[] args) {
         NotEmptyHashMap map = new NotEmptyHashMap<>();
         map.get("key");
     }
}
//////////////////////////////////////////////////////////////////////////

The test can end successfully before 8011200 but it will throw 
ArrayIndexOutOfBoundsException after 8011200. The reason is isEmpty() 
check in HashMap.getEntry() method gets passed but the actual table 
length is 0. I think the real intention of isEmpty() check is to check 
whether size in HashMap is 0 but not whether the subclass is empty, so I 
suggest to use "size == 0" instead of "isEmpty()" in get/remove methods.

Do you think this is a bug or a wrong usage of extending HashMap? I find 
there is a similar usage in javax.swing.MultiUIDefaults which extends 
Hashtable.


-- 
Regards,

Shi Jun Zhang



From peter.levart at gmail.com  Thu Jun 27 08:51:45 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 27 Jun 2013 10:51:45 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CBE978.500@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
	<51CBDDA8.4000107@gmail.com> <51CBE978.500@gmail.com>
Message-ID: <51CBFD21.1030602@gmail.com>

Hi,

Expanding on the idea of building single growing linked list of values 
and treating the array just as index for quick access which can be 
re-created at any time without synchronization or volatile publication, 
here's the attempt:


     private static class Node {
         final BigInteger value;
         Node next;
         Node(BigInteger value) { this.value = value; }
     }

     private static final Node[] powerCache;
     private static final Node[][] powerCacheIndex;
     private static final int POWER_CACHE_LINE_CHUNK = 16;

     static {
         powerCache = new Node[Character.MAX_RADIX + 1];
         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; i++) {
             powerCache[i] = new Node(BigInteger.valueOf(i));
         }
         powerCacheIndex = new Node[Character.MAX_RADIX + 1][];
     }

     private static BigInteger getRadixConversionCache(int radix, int 
exponent) {
         Node[] cacheLine = powerCacheIndex[radix];
         if (cacheLine != null && exponent < cacheLine.length) { // 
cache line is long enough
             Node node = cacheLine[exponent];
             if (node != null) {
                 return node.value;
             }
             return fillCacheLine(cacheLine, powerCache[radix], exponent);
         }
         else { // we need to extend / create cache line
             cacheLine = new Node[(exponent / POWER_CACHE_LINE_CHUNK + 
1) * POWER_CACHE_LINE_CHUNK];
             BigInteger result = fillCacheLine(cacheLine, 
powerCache[radix], exponent);
             powerCacheIndex[radix] = cacheLine; // install new line
             return result;
         }
     }

     private static BigInteger fillCacheLine(Node[] cacheLine, Node 
node0, int exponent) {
         Node node = cacheLine[0] = node0;
         for (int i = 1; i <= exponent; i++) {
             Node nextNode;
             synchronized (node) {
                 nextNode = node.next;
                 if (nextNode == null) {
                     nextNode = new Node(node.value.square());
                     node.next = nextNode;
                 }
             }
             cacheLine[i] = node = nextNode;
         }
         return node.value;
     }



What do you think?

Regards, Peter


On 06/27/2013 09:27 AM, Peter Levart wrote:
> On 06/27/2013 08:37 AM, Peter Levart wrote:
>> Hi,
>>
>> This version seems correct. Maybe just replace double volatile read 
>> at length re-check with a single one:
>>
>>
>>     private static BigInteger getRadixConversionCache(int radix, int 
>> exponent) {
>>         BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>         if (exponent < cacheLine.length)
>>             return cacheLine[exponent];
>>
>>         int oldLength = cacheLine.length;
>>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>         for (int i = oldLength; i <= exponent; i++)
>>             cacheLine[i] = cacheLine[i - 1].pow(2);
>>
>>         BigInteger[][] pc = powerCache; // volatile read again
>>         if (exponent >= pc[radix].length) {
>>             pc = pc.clone();
>>             pc[radix] = cacheLine;
>>             powerCache = pc; // volatile write, publish
>>         }
>>         return cacheLine[exponent];
>>     }
>>
>>
>> I like this, since it tries to avoid overwriting larger cacheLines 
>> with smaller ones when unexistent exponents are requested 
>> concurrently for same radix. This is good, since computation for 
>> larger exponents takes quadratically longer time (as Alan Eliasen 
>> points out) and possibility of concurrent threads stomping on each 
>> other increases. Re-reading and cloning powerCache reference at end 
>> of computation also takes care of cacheLines for other radixes that 
>> might have expanded while the computation was taking place. So the 
>> only overhead remaining is when concurrent threads are uselessly 
>> computing same results at same time. To avoid this, locking and 
>> waiting would have to be introduced which would *complicate things*.
>>
>> Regards, Peter
>
> On the other hand, it doesn't complicate thing too much. So if this 
> extra CPU time proves to be a problem, here's a variation of above 
> code which prevents multiple threads from calculating the same result 
> at the same time, by serializing computation with precise granularity:
>
>     private static class Node {
>         final BigInteger value;
>         Node next;
>         Node(BigInteger value) { this.value = value; }
>     }
>
>     private static volatile Node[][] powerCache;
>
>     static {
>         powerCache = new Node[Character.MAX_RADIX + 1][];
>         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; i++) {
>             powerCache[i] = new Node[]{new Node(BigInteger.valueOf(i))};
>         }
>     }
>
>     private static BigInteger getRadixConversionCache(int radix, int 
> exponent) {
>         Node[] cacheLine = powerCache[radix]; // volatile read
>         if (exponent < cacheLine.length)
>             return cacheLine[exponent].value;
>
>         int oldLength = cacheLine.length;
>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>         Node prevNode = cacheLine[oldLength - 1];
>         for (int i = oldLength; i <= exponent; i++) {
>             Node node;
>             synchronized (prevNode) {
>                 node = prevNode.next;
>                 if (node == null) {
>                     node = new Node(prevNode.value.pow(2));
>                     prevNode.next = node;
>                 }
>             }
>             cacheLine[i] = prevNode = node;
>         }
>
>         Node[][] pc = powerCache; // volatile read again
>         if (exponent >= pc[radix].length) {
>             pc = pc.clone();
>             pc[radix] = cacheLine;
>             powerCache = pc; // volatile write, publish
>         }
>         return cacheLine[exponent].value;
>     }
>
>
> This variation differs only in a subtelty. It wraps each BigInteger 
> with a Node, which has a link to next node in chain. Computation of 
> next node is serailized using previous node as a lock. So although 
> Nodes can end up in several arrays (which are used as index for quick 
> access), there is only a single growing chain of Nodes per radix and 
> each Node is computed by single thread.
>
> Regards, Peter
>
>>
>> On 06/26/2013 08:13 PM, Brian Burkhalter wrote:
>>> So do we have consensus on this version?
>>>
>>> Thanks for the lively "conversation."
>>>
>>> Brian
>>>
>>> On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:
>>>
>>>> Yes, like that.
>>>>
>>>> -Aleksey
>>>>
>>>> On 26.06.2013, at 10:53, Dmitry Nadezhin 
>>>>  wrote:
>>>>
>>>>>> We could check for the existing cacheLine.length right before 
>>>>>> installing
>>>>> the new one
>>>>>
>>>>> Do you mean something like this ?
>>>>>
>>>>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>>>> BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>>>> if (exponent < cacheLine.length)
>>>>>     return cacheLine[exponent];
>>>>>
>>>>> int oldLength = cacheLine.length;
>>>>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>>>> for (int i = oldLength; i < exponent + 1; i++)
>>>>>     cacheLine[i] = cacheLine[i - 1].square();
>>>>>
>>>>> if (exponent >= powerCache[radix].length) { // volatile read again
>>>>>    BigInteger[][] pc = Arrays.copyOf(powerCache);
>>>>>    pc[radix] = cacheLine;
>>>>>    powerCache = pc; // volatile write, publish
>>>>> }
>>>>> return cacheLine[exponent];
>>>>> }
>>
>



From vicente.romero at oracle.com  Thu Jun 27 08:52:38 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 27 Jun 2013 08:52:38 +0000
Subject: hg: jdk8/tl/langtools: 7066788: javah again accepts -old option
	(ineffectively) which was removed in 1.5.
Message-ID: <20130627085241.37F5A485AC@hg.openjdk.java.net>

Changeset: a47e28759666
Author:    vromero
Date:      2013-06-27 09:51 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a47e28759666

7066788: javah again accepts -old option (ineffectively) which was removed in 1.5.
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javah/JavahTask.java



From sundararajan.athijegannathan at oracle.com  Thu Jun 27 08:55:19 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Thu, 27 Jun 2013 08:55:19 +0000
Subject: hg: jdk8/tl/nashorn: 11 new changesets
Message-ID: <20130627085528.33365485AD@hg.openjdk.java.net>

Changeset: c30beaf3c42a
Author:    jlaskey
Date:      2013-06-21 14:34 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c30beaf3c42a

8010732: BigDecimal, BigInteger and Long handling in nashorn
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

+ test/script/basic/JDK-8010732.js
+ test/script/basic/JDK-8010732.js.EXPECTED

Changeset: 2ded2fc08c94
Author:    jlaskey
Date:      2013-06-22 10:12 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2ded2fc08c94

8017448: JDK-8010732.js.EXPECTED truncated
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com

! test/script/basic/JDK-8010732.js.EXPECTED

Changeset: 51a5ee93d6bc
Author:    sundar
Date:      2013-06-24 19:06 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/51a5ee93d6bc

8015959: Can't call foreign constructor
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
+ test/script/basic/JDK-8015959.js
+ test/script/basic/JDK-8015959.js.EXPECTED

Changeset: 26a345c26e62
Author:    sundar
Date:      2013-06-25 17:31 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/26a345c26e62

8015969: Needs to enforce and document that global "context" and "engine" can't be modified when running via jsr223
Reviewed-by: hannesw, jlaskey

! docs/JavaScriptingProgrammersGuide.html
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java
+ test/script/basic/JDK-8015969.js

Changeset: 39e17373d8df
Author:    sundar
Date:      2013-06-26 16:36 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/39e17373d8df

8017950: error.stack should be a string rather than an array
Reviewed-by: hannesw, jlaskey

! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/runtime/ECMAException.java
! test/script/basic/JDK-8012164.js
! test/script/basic/JDK-8012164.js.EXPECTED
+ test/script/basic/JDK-8017950.js
+ test/script/basic/JDK-8017950.js.EXPECTED
! test/script/basic/NASHORN-109.js
! test/script/basic/NASHORN-296.js
! test/script/basic/errorstack.js

Changeset: 682889823712
Author:    jlaskey
Date:      2013-06-26 08:36 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/682889823712

8008458: Strict functions dont share property map
Reviewed-by: sundar, hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/FindProperty.java
! src/jdk/nashorn/internal/runtime/Property.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/SetMethodCreator.java
! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java

Changeset: 80c66d3fd872
Author:    hannesw
Date:      2013-06-26 15:40 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/80c66d3fd872

8019157: Avoid calling ScriptObject.setProto() if possible
Reviewed-by: jlaskey, sundar

! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java
! src/jdk/nashorn/internal/codegen/ClassEmitter.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/ArrayBufferView.java
! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeArguments.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java
! src/jdk/nashorn/internal/objects/NativeBoolean.java
! src/jdk/nashorn/internal/objects/NativeDate.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/objects/NativeEvalError.java
! src/jdk/nashorn/internal/objects/NativeFloat32Array.java
! src/jdk/nashorn/internal/objects/NativeFloat64Array.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/objects/NativeInt16Array.java
! src/jdk/nashorn/internal/objects/NativeInt32Array.java
! src/jdk/nashorn/internal/objects/NativeInt8Array.java
! src/jdk/nashorn/internal/objects/NativeJSAdapter.java
! src/jdk/nashorn/internal/objects/NativeJSON.java
! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/objects/NativeJavaImporter.java
! src/jdk/nashorn/internal/objects/NativeMath.java
! src/jdk/nashorn/internal/objects/NativeNumber.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/objects/NativeRangeError.java
! src/jdk/nashorn/internal/objects/NativeReferenceError.java
! src/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java
! src/jdk/nashorn/internal/objects/NativeStrictArguments.java
! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/objects/NativeSyntaxError.java
! src/jdk/nashorn/internal/objects/NativeTypeError.java
! src/jdk/nashorn/internal/objects/NativeURIError.java
! src/jdk/nashorn/internal/objects/NativeUint16Array.java
! src/jdk/nashorn/internal/objects/NativeUint32Array.java
! src/jdk/nashorn/internal/objects/NativeUint8Array.java
! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java
! src/jdk/nashorn/internal/objects/PrototypeObject.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/FunctionScope.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/scripts/JO.java

Changeset: 635098f9f45e
Author:    sundar
Date:      2013-06-26 19:42 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/635098f9f45e

8014781: support Error.captureStackTrace
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/api/scripting/NashornException.java
! src/jdk/nashorn/internal/objects/NativeError.java
+ test/script/basic/JDK-8014781.js
+ test/script/basic/JDK-8014781.js.EXPECTED

Changeset: d1886ad46f0c
Author:    jlaskey
Date:      2013-06-26 12:38 -0300
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d1886ad46f0c

8019175: Simplify ScriptObject.modifyOwnProperty
Reviewed-by: hannesw
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java

Changeset: f9c855b828fe
Author:    sundar
Date:      2013-06-27 13:24 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f9c855b828fe

8019226: line number not generated for first statement if it is on the same function declaration line
Reviewed-by: jlaskey, hannesw

! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8019226.js
+ test/script/basic/JDK-8019226.js.EXPECTED

Changeset: 5ec4762d9df0
Author:    sundar
Date:      2013-06-27 13:47 +0530
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5ec4762d9df0

Merge




From vicente.romero at oracle.com  Thu Jun 27 08:57:12 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 27 Jun 2013 08:57:12 +0000
Subject: hg: jdk8/tl/langtools: 8017609: javac,
	ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory)
Message-ID: <20130627085715.15B83485AF@hg.openjdk.java.net>

Changeset: 8e3d391c88c6
Author:    vromero
Date:      2013-06-27 09:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e3d391c88c6

8017609: javac, ClassFile.read(Path) should be ClassFile.read(Path, Attribute.Factory)
Reviewed-by: jjg

! src/share/classes/com/sun/tools/classfile/ClassFile.java



From chris.hegarty at oracle.com  Thu Jun 27 09:03:06 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 27 Jun 2013 10:03:06 +0100
Subject: Review Request: JDK-8019227: JDK-8010325 broke the old build
In-Reply-To: <51CBD813.6080807@oracle.com>
References: <51CBC1A7.5020206@oracle.com> <51CBD813.6080807@oracle.com>
Message-ID: <51CBFFCA.2030904@oracle.com>

On 27/06/2013 07:13, Alan Bateman wrote:
> On 27/06/2013 05:37, Brad Wetmore wrote:
>> Brent/Alan/Mike,
>>
>> Hashing.java was removed from the JDK workspace, but was not removed
>> from the old java/java/FILES_java.gmk. Things that still depend on the
>> old build (JCE/deploy) are currently broken.
>>
>> http://cr.openjdk.java.net/~wetmore/8019227/webrev.00/
>>
>> Brad
>>
>> P.S. I'm very aware that we need to move off the old build soon and am
>> getting closer to finally working on it with Erik, and that the old
>> build isn't complete. But it's complete enough for the JCE
>> dependencies. Unfortunately, this isn't a simple transition
>> (JDK-8006350), and this is a quick fix to get the JCE bits built.
>
> The old build has not produced usable bits for several months, it may
> not have been failing but if you look closely (or run the tests) then
> you'll see that there are several things missing. On build-dev then
> you'll probably have seen a mail or two from me where I was trying to
> encourage the build group to set a date to finally retire and remove the
> old build - this is because the old build is just a tax on every change
> that needs to touch the build.
>
> Anyway, the change looks okay but I strongly encourage you to put in the
> time to resolve the usability or others ssues that arise when working on
> JCE.

+1 ( on the actual changes, and moving off the old build )

-Chris.

>
> -Alan


From erik.joelsson at oracle.com  Thu Jun 27 08:36:04 2013
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 27 Jun 2013 08:36:04 +0000
Subject: hg: jdk8/tl/langtools: 8014513: Sjavac doesn't detect 32-bit jvm
	properly
Message-ID: <20130627083609.C2E77485AA@hg.openjdk.java.net>

Changeset: dcc6a52bf363
Author:    erikj
Date:      2013-06-27 10:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dcc6a52bf363

8014513: Sjavac doesn't detect 32-bit jvm properly
Reviewed-by: jjg

! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java



From peter.levart at gmail.com  Thu Jun 27 09:17:26 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 27 Jun 2013 11:17:26 +0200
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CBFD21.1030602@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
	<51CBDDA8.4000107@gmail.com> <51CBE978.500@gmail.com>
	<51CBFD21.1030602@gmail.com>
Message-ID: <51CC0326.9080906@gmail.com>

Sorry for high frequency of messages.

This one is even better. powerCacheIndex need not be holding Nodes, but 
BigIntegers instead. So no indirection on fast-path:


     private static class Node {
         final BigInteger value;
         Node next;
         Node(BigInteger value) { this.value = value; }
     }

     private static final Node[] powerCache;
     private static final BigInteger[][] powerCacheIndex;
     private static final int POWER_CACHE_LINE_CHUNK = 16;

     static {
         powerCache = new Node[Character.MAX_RADIX + 1];
         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; i++) {
             powerCache[i] = new Node(BigInteger.valueOf(i));
         }
         powerCacheIndex = new BigInteger[Character.MAX_RADIX + 1][];
     }

     private static BigInteger getRadixConversionCache(int radix, int 
exponent) {
         BigInteger[] cacheLine = powerCacheIndex[radix];
         if (cacheLine != null && exponent < cacheLine.length) { // 
cache line is long enough
             BigInteger value = cacheLine[exponent];
             if (value != null) {
                 return value;
             }
             return fillCacheLine(cacheLine, powerCache[radix], exponent);
         }
         else { // we need to extend / create cache line
             cacheLine = new BigInteger[(exponent / 
POWER_CACHE_LINE_CHUNK + 1) * POWER_CACHE_LINE_CHUNK];
             BigInteger result = fillCacheLine(cacheLine, 
powerCache[radix], exponent);
             powerCacheIndex[radix] = cacheLine; // install new line
             return result;
         }
     }

     private static BigInteger fillCacheLine(BigInteger[] cacheLine, 
Node node, int exponent) {
         cacheLine[0] = node.value;
         for (int i = 1; i <= exponent; i++) {
             synchronized (node) {
                 if (node.next == null) {
                     node.next = new Node(node.value.pow(2));
                 }
             }
             node = node.next;
             cacheLine[i] = node.value;
         }
         return node.value;
     }


Regards, Peter

On 06/27/2013 10:51 AM, Peter Levart wrote:
> Hi,
>
> Expanding on the idea of building single growing linked list of values 
> and treating the array just as index for quick access which can be 
> re-created at any time without synchronization or volatile 
> publication, here's the attempt:
>
>
>     private static class Node {
>         final BigInteger value;
>         Node next;
>         Node(BigInteger value) { this.value = value; }
>     }
>
>     private static final Node[] powerCache;
>     private static final Node[][] powerCacheIndex;
>     private static final int POWER_CACHE_LINE_CHUNK = 16;
>
>     static {
>         powerCache = new Node[Character.MAX_RADIX + 1];
>         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; i++) {
>             powerCache[i] = new Node(BigInteger.valueOf(i));
>         }
>         powerCacheIndex = new Node[Character.MAX_RADIX + 1][];
>     }
>
>     private static BigInteger getRadixConversionCache(int radix, int 
> exponent) {
>         Node[] cacheLine = powerCacheIndex[radix];
>         if (cacheLine != null && exponent < cacheLine.length) { // 
> cache line is long enough
>             Node node = cacheLine[exponent];
>             if (node != null) {
>                 return node.value;
>             }
>             return fillCacheLine(cacheLine, powerCache[radix], exponent);
>         }
>         else { // we need to extend / create cache line
>             cacheLine = new Node[(exponent / POWER_CACHE_LINE_CHUNK + 
> 1) * POWER_CACHE_LINE_CHUNK];
>             BigInteger result = fillCacheLine(cacheLine, 
> powerCache[radix], exponent);
>             powerCacheIndex[radix] = cacheLine; // install new line
>             return result;
>         }
>     }
>
>     private static BigInteger fillCacheLine(Node[] cacheLine, Node 
> node0, int exponent) {
>         Node node = cacheLine[0] = node0;
>         for (int i = 1; i <= exponent; i++) {
>             Node nextNode;
>             synchronized (node) {
>                 nextNode = node.next;
>                 if (nextNode == null) {
>                     nextNode = new Node(node.value.square());
>                     node.next = nextNode;
>                 }
>             }
>             cacheLine[i] = node = nextNode;
>         }
>         return node.value;
>     }
>
>
>
> What do you think?
>
> Regards, Peter
>
>
> On 06/27/2013 09:27 AM, Peter Levart wrote:
>> On 06/27/2013 08:37 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> This version seems correct. Maybe just replace double volatile read 
>>> at length re-check with a single one:
>>>
>>>
>>>     private static BigInteger getRadixConversionCache(int radix, int 
>>> exponent) {
>>>         BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>>         if (exponent < cacheLine.length)
>>>             return cacheLine[exponent];
>>>
>>>         int oldLength = cacheLine.length;
>>>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>>         for (int i = oldLength; i <= exponent; i++)
>>>             cacheLine[i] = cacheLine[i - 1].pow(2);
>>>
>>>         BigInteger[][] pc = powerCache; // volatile read again
>>>         if (exponent >= pc[radix].length) {
>>>             pc = pc.clone();
>>>             pc[radix] = cacheLine;
>>>             powerCache = pc; // volatile write, publish
>>>         }
>>>         return cacheLine[exponent];
>>>     }
>>>
>>>
>>> I like this, since it tries to avoid overwriting larger cacheLines 
>>> with smaller ones when unexistent exponents are requested 
>>> concurrently for same radix. This is good, since computation for 
>>> larger exponents takes quadratically longer time (as Alan Eliasen 
>>> points out) and possibility of concurrent threads stomping on each 
>>> other increases. Re-reading and cloning powerCache reference at end 
>>> of computation also takes care of cacheLines for other radixes that 
>>> might have expanded while the computation was taking place. So the 
>>> only overhead remaining is when concurrent threads are uselessly 
>>> computing same results at same time. To avoid this, locking and 
>>> waiting would have to be introduced which would *complicate things*.
>>>
>>> Regards, Peter
>>
>> On the other hand, it doesn't complicate thing too much. So if this 
>> extra CPU time proves to be a problem, here's a variation of above 
>> code which prevents multiple threads from calculating the same result 
>> at the same time, by serializing computation with precise granularity:
>>
>>     private static class Node {
>>         final BigInteger value;
>>         Node next;
>>         Node(BigInteger value) { this.value = value; }
>>     }
>>
>>     private static volatile Node[][] powerCache;
>>
>>     static {
>>         powerCache = new Node[Character.MAX_RADIX + 1][];
>>         for (int i = Character.MIN_RADIX; i <= Character.MAX_RADIX; 
>> i++) {
>>             powerCache[i] = new Node[]{new Node(BigInteger.valueOf(i))};
>>         }
>>     }
>>
>>     private static BigInteger getRadixConversionCache(int radix, int 
>> exponent) {
>>         Node[] cacheLine = powerCache[radix]; // volatile read
>>         if (exponent < cacheLine.length)
>>             return cacheLine[exponent].value;
>>
>>         int oldLength = cacheLine.length;
>>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>         Node prevNode = cacheLine[oldLength - 1];
>>         for (int i = oldLength; i <= exponent; i++) {
>>             Node node;
>>             synchronized (prevNode) {
>>                 node = prevNode.next;
>>                 if (node == null) {
>>                     node = new Node(prevNode.value.pow(2));
>>                     prevNode.next = node;
>>                 }
>>             }
>>             cacheLine[i] = prevNode = node;
>>         }
>>
>>         Node[][] pc = powerCache; // volatile read again
>>         if (exponent >= pc[radix].length) {
>>             pc = pc.clone();
>>             pc[radix] = cacheLine;
>>             powerCache = pc; // volatile write, publish
>>         }
>>         return cacheLine[exponent].value;
>>     }
>>
>>
>> This variation differs only in a subtelty. It wraps each BigInteger 
>> with a Node, which has a link to next node in chain. Computation of 
>> next node is serailized using previous node as a lock. So although 
>> Nodes can end up in several arrays (which are used as index for quick 
>> access), there is only a single growing chain of Nodes per radix and 
>> each Node is computed by single thread.
>>
>> Regards, Peter
>>
>>>
>>> On 06/26/2013 08:13 PM, Brian Burkhalter wrote:
>>>> So do we have consensus on this version?
>>>>
>>>> Thanks for the lively "conversation."
>>>>
>>>> Brian
>>>>
>>>> On Jun 26, 2013, at 12:05 AM, Aleksey Shipilev wrote:
>>>>
>>>>> Yes, like that.
>>>>>
>>>>> -Aleksey
>>>>>
>>>>> On 26.06.2013, at 10:53, Dmitry Nadezhin 
>>>>>  wrote:
>>>>>
>>>>>>> We could check for the existing cacheLine.length right before 
>>>>>>> installing
>>>>>> the new one
>>>>>>
>>>>>> Do you mean something like this ?
>>>>>>
>>>>>> BigInteger getRadixConversionCache(int radix, int exponent) {
>>>>>> BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>>>>> if (exponent < cacheLine.length)
>>>>>>     return cacheLine[exponent];
>>>>>>
>>>>>> int oldLength = cacheLine.length;
>>>>>> cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>>>>> for (int i = oldLength; i < exponent + 1; i++)
>>>>>>     cacheLine[i] = cacheLine[i - 1].square();
>>>>>>
>>>>>> if (exponent >= powerCache[radix].length) { // volatile read again
>>>>>>    BigInteger[][] pc = Arrays.copyOf(powerCache);
>>>>>>    pc[radix] = cacheLine;
>>>>>>    powerCache = pc; // volatile write, publish
>>>>>> }
>>>>>> return cacheLine[exponent];
>>>>>> }
>>>
>>
>



From paul.sandoz at oracle.com  Thu Jun 27 09:38:39 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 27 Jun 2013 11:38:39 +0200
Subject: RFR 8017329 8b92-lambda regression: TreeSet("a",
	"b").stream().substream(1).parallel().iterator() is empty
Message-ID: <6C3ED24A-9A28-403E-B995-9C09C69571C2@oracle.com>

Hi,

Please review a fix for a regression with using Stream.substream for an ORDERED but not SUBSIZED spliterator that does not split.

This is based off:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8012987-slice/webrev/

which is blocked waiting for the Comparator API webrev to go into tl, which should be soon (waiting on CCC approval).

Paul.

# HG changeset patch
# User psandoz
# Date 1372324256 -7200
# Node ID 3459ac0d695ffdf2f5120e63a9a4bb79a0af40dc
# Parent  d4cd5e16ac8f279e05974cdb2f6281c5f24e484c
8017329: 8b92-lambda regression: TreeSet("a", "b").stream().substream(1).parallel().iterator() is empty
Reviewed-by:

diff -r d4cd5e16ac8f -r 3459ac0d695f src/share/classes/java/util/stream/SliceOps.java
--- a/src/share/classes/java/util/stream/SliceOps.java	Thu Jun 27 11:06:17 2013 +0200
+++ b/src/share/classes/java/util/stream/SliceOps.java	Thu Jun 27 11:10:56 2013 +0200
@@ -598,9 +598,9 @@
                 final Node.Builder nb = op.makeNodeBuilder(sizeIfKnown, generator);
                 Sink opSink = op.opWrapSink(helper.getStreamAndOpFlags(), nb);
                 helper.copyIntoWithCancel(helper.wrapSink(opSink), spliterator);
-                // It is necessary to truncate here since the result at the root
-                // can only be set once
-                return doTruncate(nb.build());
+                // There is no need to truncate since the op performs the
+                // skipping and limiting of elements
+                return nb.build();
             }
             else {
                 Node node = helper.wrapAndCopyInto(helper.makeNodeBuilder(-1, generator),
diff -r d4cd5e16ac8f -r 3459ac0d695f test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
--- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java	Thu Jun 27 11:06:17 2013 +0200
+++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java	Thu Jun 27 11:10:56 2013 +0200
@@ -26,13 +26,16 @@
 
 import java.util.*;
 import java.util.concurrent.atomic.AtomicInteger;
+import java.util.function.Consumer;
 import java.util.function.Function;
+import java.util.stream.Collectors;
 import java.util.stream.DoubleStream;
 import java.util.stream.IntStream;
 import java.util.stream.LambdaTestHelpers;
 import java.util.stream.LongStream;
 import java.util.stream.OpTestCase;
 import java.util.stream.Stream;
+import java.util.stream.StreamSupport;
 import java.util.stream.StreamTestDataProvider;
 import java.util.stream.TestData;
 
@@ -192,6 +195,53 @@
         }
     }
 
+    public void testSkipLimitOpsWithNonSplittingSpliterator() {
+        class NonSplittingNotSubsizedOrderedSpliterator implements Spliterator {
+            Spliterator s;
+
+            NonSplittingNotSubsizedOrderedSpliterator(Spliterator s) {
+                assert s.hasCharacteristics(Spliterator.ORDERED);
+                this.s = s;
+            }
+
+            @Override
+            public boolean tryAdvance(Consumer action) {
+                return s.tryAdvance(action);
+            }
+
+            @Override
+            public void forEachRemaining(Consumer action) {
+                s.forEachRemaining(action);
+            }
+
+            @Override
+            public Spliterator trySplit() {
+                return null;
+            }
+
+            @Override
+            public long estimateSize() {
+                return s.estimateSize();
+            }
+
+            @Override
+            public int characteristics() {
+                return s.characteristics() & ~(Spliterator.SUBSIZED);
+            }
+
+            @Override
+            public Comparator getComparator() {
+                return s.getComparator();
+            }
+        }
+        List list = IntStream.range(0, 100).boxed().collect(Collectors.toList());
+        TestData.OfRef data = TestData.Factory.ofSupplier(
+                "Non splitting, not SUBSIZED, ORDERED, stream",
+                () -> StreamSupport.stream(new NonSplittingNotSubsizedOrderedSpliterator<>(list.spliterator())));
+
+        testSkipLimitOps("testSkipLimitOpsWithNonSplittingSpliterator", data);
+    }
+
     @Test(dataProvider = "StreamTestData", dataProviderClass = StreamTestDataProvider.class)
     public void testLimitOps(String name, TestData.OfRef data) {
         List limits = sizes(data.size());



From chris.hegarty at oracle.com  Thu Jun 27 09:26:09 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Thu, 27 Jun 2013 09:26:09 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130627092645.22335485B2@hg.openjdk.java.net>

Changeset: 370e7beff8a0
Author:    wetmore
Date:      2013-06-27 10:19 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/370e7beff8a0

8019227: JDK-8010325 broke the old build
Reviewed-by: alanb, chegar

! make/java/java/FILES_java.gmk

Changeset: 4e69a7dfbeac
Author:    chegar
Date:      2013-06-27 10:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e69a7dfbeac

Merge




From bourges.laurent at gmail.com  Thu Jun 27 09:57:14 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Thu, 27 Jun 2013 11:57:14 +0200
Subject: JVM application shutdown hooks
Message-ID: 

Dear members,

I have a problem within an external library using one JVM Shutdown hook to
perform resource cleanup (socket, lock file deletion ...) that seems buggy
in java web start environment: sometimes the JVM reports an
IllegalStateException happenning during that shutdown hook.

This library uses java.util.logging to log warnings and exceptions but none
is logged (console or java trace files).

The 'lost' log messages is related to the LogManager's shutdown hook:
    // This private class is used as a shutdown hook.
    // It does a "reset" to close all open handlers.
    private class Cleaner extends Thread {

        private Cleaner() {
            /* Set context class loader to null in order to avoid
             * keeping a strong reference to an application classloader.
             */
            this.setContextClassLoader(null);
        }

        public void run() {
            // This is to ensure the LogManager. is completed
            // before synchronized block. Otherwise deadlocks are possible.
            LogManager mgr = manager;

            // If the global handlers haven't been initialized yet, we
            // don't want to initialize them just so we can close them!
            synchronized (LogManager.this) {
                // Note that death is imminent.
                deathImminent = true;
                initializedGlobalHandlers = true;
            }

            // Do a reset to close all active handlers.
            reset();
        }
    }

Without any log handler, the log messages are lost during shutdown !
I think it is annoying as it avoids me getting log and exceptions ...

FYI, the ApplicationShutdownHooks class executes all 'application' hooks
concurrently:
    static void runHooks() {
        Collection threads;
        synchronized(ApplicationShutdownHooks.class) {
            threads = hooks.keySet();
            hooks = null;
        }

        for (Thread hook : threads) {
            hook.start();
        }
        for (Thread hook : threads) {
            try {
                hook.join();
            } catch (InterruptedException x) { }
        }
    }
So it is not possible to define hook priorities ...

However, I looked at the JVM Shutdown class which supports hook priorities
and I think that the J.U.L Cleaner hook should run after all application
hooks.
Here are the current Shutdown priorities:
    // The system shutdown hooks are registered with a predefined slot.
    // The list of shutdown hooks is as follows:
    // (0) Console restore hook
    // (1) Application hooks
    // (2) DeleteOnExit hook

Moreover, as a RFE, it could be useful for applications to be able to
define hook priorities within an application:
I did that several times registering only 1 shutdown hook and handling
correct ordering on my own ... but could be supported by the JDK itself.

Finally, here are (below) the Open JDK8 usages of Runtime.addShutdownHook
[19 occurrences] which are more system hooks than application hooks:
com.sun.imageio.stream
StreamCloser.java
StreamCloser
addToQueue

run
  101:  Runtime.getRuntime().addShutdownHook(streamCloser);
java.util.logging
LogManager.java
LogManager
LogManager
  255:  Runtime.getRuntime().addShutdownHook(new Cleaner());
sun.font
SunFontManager.java
SunFontManager
createFont2D

run
2538:  Runtime.getRuntime().addShutdownHook(fileCloser);
sun.rmi.server
Activation.java
Activation
init
  240:  Runtime.getRuntime().addShutdownHook(shutdownHook);
sun.tools.jstat

sun.awt.shell
Win32ShellFolderManager2.java
Win32ShellFolderManager2
ComInvoker
ComInvoker
>
run
  493:  Runtime.getRuntime().addShutdownHook(
sun.awt.windows
WToolkit.java
WToolkit
registerShutdownHook
>
run
  285:  Runtime.getRuntime().addShutdownHook(shutdown);
sun.java2d.d3d
D3DScreenUpdateManager.java
D3DScreenUpdateManager
D3DScreenUpdateManager

run
  112:  Runtime.getRuntime().addShutdownHook(shutdown);
java.util.prefs
FileSystemPreferences.java
FileSystemPreferences
>
run
  439:  Runtime.getRuntime().addShutdownHook(new Thread() {
sun.awt.X11
XToolkit.java
XToolkit
init
>
run
  350:  Runtime.getRuntime().addShutdownHook(shutdownThread);
sun.awt
X11GraphicsDevice.java
X11GraphicsDevice
setDisplayMode
>
run
  445:  Runtime.getRuntime().addShutdownHook(t);
java.util.prefs
MacOSXPreferencesFile.java
MacOSXPreferencesFile
timer
  356:  Runtime.getRuntime().addShutdownHook(flushThread);
sun.font
CFontManager.java
CFontManager
createFont2D
>
run
  232:  Runtime.getRuntime().addShutdownHook(fileCloser);
sun.lwawt
LWToolkit.java
LWToolkit
init
    83:  Runtime.getRuntime().addShutdownHook(

I hope that these hooks are already supporting concurrency execution (awt
?) but someone should check if there is no dependencies between them (like
systemd or rc scripts does).

PS: As shutdown hooks are given by the application as Thread class
instances, I suspect also a possible classloader leak ? In Java web start
environment, it may be the cause of my problems as I do not know if the
hook thread is still within the application class loader ...

Laurent Bourg?s


From chris.hegarty at oracle.com  Thu Jun 27 10:34:09 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 27 Jun 2013 11:34:09 +0100
Subject: test with a 3rd party jar file?
In-Reply-To: <51CBEEAD.3050308@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8E9A5.8010002@oracle.com>
	<51CAEA28.1020704@oracle.com> <51CBEEAD.3050308@oracle.com>
Message-ID: <51CC1521.9000904@oracle.com>

On 27/06/2013 08:50, huizhe wang wrote:
> Hi Chris,
>
> Thanks for the information! I'll give it a try.
>
> On 6/26/2013 6:18 AM, Chris Hegarty wrote:
>> The streams package recently added tests for exercising
>> package-private implementation.
>>
>> Top level dir contain the TEST.properties to add to the bootclasspath:
>
> Do you mean TEST.properties need to be in the top level directory (e.g.
> javax/xml/jaxp), can it be put anywhere that contains a block of tests?

Yes, I believe so. You must put it somewhere that it does not impact on 
other tests, since all tests below that directory hierarchy will be 
impacted by it.

> In my particular case, I only want to run a single test with the jar
> file on the bootclasspath.

Create a directory structure somewhere in the regression library 
appropriate to your changes, say javax/xml/jaxp/boottest/. Create 
javax/xml/jaxp/boottest/TEST.properties. Then put your test at 
javax/xml/jaxp/boottest/xxx/yyy/zzz/Test.java ( where xxx.yyy.zzz is 
your package name ).

-Chris.

>
> Thanks,
> Joe
>
>>
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/
>>
>>
>> Example, individual test, whose test is in the java.util.stream package:
>>
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
>>
>>
>> -Chris.
>>
>> On 25/06/2013 01:51, huizhe wang wrote:
>>> Thanks Sean and Rob.
>>>
>>> Yes, I was told before to avoid shell scripts in tests. I'll wait till
>>> after your investigation to see what's the best to do in this case.
>>>
>>> -Joe
>>>
>>> On 6/24/2013 3:42 PM, Rob McKenna wrote:
>>>> Some interesting conversations were had lately about shell scripts
>>>> during Joe Darcy's recent infrastructure tech talk. In particular
>>>> around the idea of a "jdk.testing" package to provide libraries that
>>>> would help with the types of operations seen in shell scripts. I'm
>>>> really hoping to spend some time on this myself over the coming weeks.
>>>> (in an effort to at least understand why we need shell scripts and
>>>> whether we could do something else instead)
>>>>
>>>> In any case it should be possible to simply replace the script with a
>>>> java program that does the same thing. That would require fiddling
>>>> with Process however, and its debatable as to whether that would
>>>> result in fewer test failures. (shell scripts counting for a
>>>> proportionally large number of those failures) JSR199 might help to
>>>> reduce the amount of ProcessBuilders required in this instance.
>>>>
>>>> -Rob
>


From aleksey.shipilev at oracle.com  Thu Jun 27 11:18:02 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 27 Jun 2013 15:18:02 +0400
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CBDDA8.4000107@gmail.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
	<51CBDDA8.4000107@gmail.com>
Message-ID: <51CC1F6A.4010108@oracle.com>

On 06/27/2013 10:37 AM, Peter Levart wrote:
> Hi,
> 
> This version seems correct. Maybe just replace double volatile read at
> length re-check with a single one:
> 
> 
>     private static BigInteger getRadixConversionCache(int radix, int
> exponent) {
>         BigInteger[] cacheLine = powerCache[radix]; // volatile read
>         if (exponent < cacheLine.length)
>             return cacheLine[exponent];
> 
>         int oldLength = cacheLine.length;
>         cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>         for (int i = oldLength; i <= exponent; i++)
>             cacheLine[i] = cacheLine[i - 1].pow(2);
> 
>         BigInteger[][] pc = powerCache; // volatile read again
>         if (exponent >= pc[radix].length) {
>             pc = pc.clone();
>             pc[radix] = cacheLine;
>             powerCache = pc; // volatile write, publish
>         }
>         return cacheLine[exponent];
>     }
> 

Yes, I'm voting for this one. All other improvements Peter had
suggested, while interesting, seem to not to worth the trouble.

-Aleksey.




From vicente.romero at oracle.com  Thu Jun 27 15:04:46 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 27 Jun 2013 15:04:46 +0000
Subject: hg: jdk8/tl/langtools: 8016099: Some @SuppressWarnings annotations
	ignored ( unchecked, rawtypes )
Message-ID: <20130627150449.A6E2D485C1@hg.openjdk.java.net>

Changeset: e42c27026290
Author:    vromero
Date:      2013-06-27 16:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e42c27026290

8016099: Some @SuppressWarnings annotations ignored ( unchecked, rawtypes )
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/T8016099/UncheckedWarningRegressionTest.java
+ test/tools/javac/T8016099/UncheckedWarningRegressionTest.out



From vicente.romero at oracle.com  Thu Jun 27 15:07:31 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 27 Jun 2013 15:07:31 +0000
Subject: hg: jdk8/tl/langtools: 7008643: inlined finally clauses confuse
	debuggers
Message-ID: <20130627150734.B03D6485C2@hg.openjdk.java.net>

Changeset: d137ce373c4c
Author:    vromero
Date:      2013-06-27 16:06 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d137ce373c4c

7008643: inlined finally clauses confuse debuggers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/T7008643/InlinedFinallyConfuseDebuggersTest.java



From paul.sandoz at oracle.com  Thu Jun 27 15:33:05 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 27 Jun 2013 17:33:05 +0200
Subject: RFR 8011427 java.util.concurrent collection Spliterator
	implementations 
Message-ID: <14D8BCB6-2FF5-4163-8A9B-F76E56C2B199@oracle.com>

Hi,

This webrev contains updates of java.util.concurrent collections from 166:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8011427-concur-splits/webrev/

More specifically:

- spliterator implementations (which are tested by the existing spltierator tests).

- various doc updates.

- and other updates that are tricky to separate from the above as continual improvements are made, especially to CopyOnWriteArrayList and ConcurrentSkipListMap.

ConcurrentHashMap, ConcurrentMap and ConcurrentNavigableMap will be dealt with in a separate webrev, as will other aspects of 166.

Most of this code has been in the lambda repo for quite a while (the diff between 166 and lambda is much much smaller than the diff between tl and lambda). This webrev was derived from the lambda code base after first syncing lambda with associated files from 166.

Paul.

From paul.sandoz at oracle.com  Thu Jun 27 15:57:11 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 27 Jun 2013 17:57:11 +0200
Subject: RFR 8011427 java.util.concurrent collection Spliterator
	implementations
In-Reply-To: <14D8BCB6-2FF5-4163-8A9B-F76E56C2B199@oracle.com>
References: <14D8BCB6-2FF5-4163-8A9B-F76E56C2B199@oracle.com>
Message-ID: <455C8AA4-D8CE-4F7C-A14B-97C444AD4631@oracle.com>

I forgot to mention this patch is based off the comparator's patch which is required by updates to ConcurrentSkipListMap.java.

Paul.

On Jun 27, 2013, at 5:33 PM, Paul Sandoz  wrote:

> Hi,
> 
> This webrev contains updates of java.util.concurrent collections from 166:
> 
>  http://cr.openjdk.java.net/~psandoz/tl/JDK-8011427-concur-splits/webrev/
> 
> More specifically:
> 
> - spliterator implementations (which are tested by the existing spltierator tests).
> 
> - various doc updates.
> 
> - and other updates that are tricky to separate from the above as continual improvements are made, especially to CopyOnWriteArrayList and ConcurrentSkipListMap.
> 
> ConcurrentHashMap, ConcurrentMap and ConcurrentNavigableMap will be dealt with in a separate webrev, as will other aspects of 166.
> 
> Most of this code has been in the lambda repo for quite a while (the diff between 166 and lambda is much much smaller than the diff between tl and lambda). This webrev was derived from the lambda code base after first syncing lambda with associated files from 166.
> 
> Paul.



From huizhe.wang at oracle.com  Thu Jun 27 16:04:16 2013
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 27 Jun 2013 09:04:16 -0700
Subject: test with a 3rd party jar file?
In-Reply-To: <51CC1521.9000904@oracle.com>
References: <1607722475.24835.1372093442657.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C882E0.9030006@oracle.com> <51C8A2FB.4030805@oracle.com>
	<51C8CB4C.90604@oracle.com> <51C8E9A5.8010002@oracle.com>
	<51CAEA28.1020704@oracle.com> <51CBEEAD.3050308@oracle.com>
	<51CC1521.9000904@oracle.com>
Message-ID: <51CC6280.9070502@oracle.com>

Thanks Chris for the instructions!

Joe

On 6/27/2013 3:34 AM, Chris Hegarty wrote:
> On 27/06/2013 08:50, huizhe wang wrote:
>> Hi Chris,
>>
>> Thanks for the information! I'll give it a try.
>>
>> On 6/26/2013 6:18 AM, Chris Hegarty wrote:
>>> The streams package recently added tests for exercising
>>> package-private implementation.
>>>
>>> Top level dir contain the TEST.properties to add to the bootclasspath:
>>
>> Do you mean TEST.properties need to be in the top level directory (e.g.
>> javax/xml/jaxp), can it be put anywhere that contains a block of tests?
>
> Yes, I believe so. You must put it somewhere that it does not impact 
> on other tests, since all tests below that directory hierarchy will be 
> impacted by it.
>
>> In my particular case, I only want to run a single test with the jar
>> file on the bootclasspath.
>
> Create a directory structure somewhere in the regression library 
> appropriate to your changes, say javax/xml/jaxp/boottest/. Create 
> javax/xml/jaxp/boottest/TEST.properties. Then put your test at 
> javax/xml/jaxp/boottest/xxx/yyy/zzz/Test.java ( where xxx.yyy.zzz is 
> your package name ).
>
> -Chris.
>
>>
>> Thanks,
>> Joe
>>
>>>
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/ 
>>>
>>>
>>>
>>> Example, individual test, whose test is in the java.util.stream 
>>> package:
>>>
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/510035b7bbbb/test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java 
>>>
>>>
>>>
>>> -Chris.
>>>
>>> On 25/06/2013 01:51, huizhe wang wrote:
>>>> Thanks Sean and Rob.
>>>>
>>>> Yes, I was told before to avoid shell scripts in tests. I'll wait till
>>>> after your investigation to see what's the best to do in this case.
>>>>
>>>> -Joe
>>>>
>>>> On 6/24/2013 3:42 PM, Rob McKenna wrote:
>>>>> Some interesting conversations were had lately about shell scripts
>>>>> during Joe Darcy's recent infrastructure tech talk. In particular
>>>>> around the idea of a "jdk.testing" package to provide libraries that
>>>>> would help with the types of operations seen in shell scripts. I'm
>>>>> really hoping to spend some time on this myself over the coming 
>>>>> weeks.
>>>>> (in an effort to at least understand why we need shell scripts and
>>>>> whether we could do something else instead)
>>>>>
>>>>> In any case it should be possible to simply replace the script with a
>>>>> java program that does the same thing. That would require fiddling
>>>>> with Process however, and its debatable as to whether that would
>>>>> result in fewer test failures. (shell scripts counting for a
>>>>> proportionally large number of those failures) JSR199 might help to
>>>>> reduce the amount of ProcessBuilders required in this instance.
>>>>>
>>>>> -Rob
>>



From jonathan.gibbons at oracle.com  Thu Jun 27 16:07:16 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 27 Jun 2013 16:07:16 +0000
Subject: hg: jdk8/tl/langtools: 8015720: since tag isn't copied while
	generating JavaFX documentation
Message-ID: <20130627160719.CBD6E485C4@hg.openjdk.java.net>

Changeset: 26437287529d
Author:    janvalenta
Date:      2013-06-27 17:47 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26437287529d

8015720: since tag isn't copied while generating JavaFX documentation
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! test/com/sun/javadoc/testJavaFX/C.java
! test/com/sun/javadoc/testJavaFX/TestJavaFX.java



From stuart.marks at oracle.com  Thu Jun 27 16:21:50 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 27 Jun 2013 09:21:50 -0700
Subject: RFR: 8019224 : add exception chaining to RMI CGIHandler
Message-ID: <51CC669E.9050406@oracle.com>

Hi all,

Here's a simple webrev to add exception chaining (constructor overloads with 
the 'cause' parameter) to some internal exception types used in RMI.

We've been getting some test failures that go through this area and I suspect 
that this code is discarding some diagnostic information.

http://cr.openjdk.java.net/~smarks/reviews/8019224/webrev.0/

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019224

Thanks!

s'marks



From joe.darcy at oracle.com  Thu Jun 27 16:22:15 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 09:22:15 -0700
Subject: RFR: 8019224 : add exception chaining to RMI CGIHandler
In-Reply-To: <51CC669E.9050406@oracle.com>
References: <51CC669E.9050406@oracle.com>
Message-ID: <51CC66B7.9080500@oracle.com>

Looks fine Stuart; cheers,

-Joe

On 06/27/2013 09:21 AM, Stuart Marks wrote:
> Hi all,
>
> Here's a simple webrev to add exception chaining (constructor 
> overloads with the 'cause' parameter) to some internal exception types 
> used in RMI.
>
> We've been getting some test failures that go through this area and I 
> suspect that this code is discarding some diagnostic information.
>
> http://cr.openjdk.java.net/~smarks/reviews/8019224/webrev.0/
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019224
>
> Thanks!
>
> s'marks
>



From kumar.x.srinivasan at oracle.com  Thu Jun 27 16:43:02 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 27 Jun 2013 09:43:02 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51C9D85D.6080905@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
Message-ID: <51CC6B96.8080607@oracle.com>

If this is to be undone after the correct zip fix, why not add the 
@ignore for now ?
and enable this when 8015666 is fixed correctly.

Kumar

> This is fine to be a workaround for the test case for now. It probably 
> will need to be
> undo-ed after the propose change for #8015666 get integrated.
>
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>
> The proposal for #8015666 is to keep the "existing" behavior of 
> ZipEntry.getTime()
> to return a LastModifiedTime converted from the zip entry's 
> ms-dos-formatted date/time
> field by using the "default" timezone. A new pair 
> ZipEntry.get/setLastModifiedTime()
> will be added to access the "real" UTC time stored in the zip entry, 
> if presents.
>
> The API doc will be updated accordingly as well to explicitly explain 
> the source of the
> date/time and the its timezone sensitive conversion.
>
> -Sherman
>
> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>> Hello,
>>
>> Please review this simple patch which updates regression test
>> langtools/tools/javac/T6725036.java to offset the time returned by
>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>
>> Please note that this patch is intended to address the test failures,
>> and that I will be immediately opening a new bug to investigate and
>> address deeper issues, and also to properly document the API.
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~emc/8016760/
>>
>> The bug report is here:
>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>
>> Thanks,
>> Eric
>



From Lance.Andersen at oracle.com  Thu Jun 27 16:56:38 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Thu, 27 Jun 2013 12:56:38 -0400
Subject: review request for bug: 8017471 clean up of JDBC doclint errors
Message-ID: 

Hi all,

Need a reviewer for 8017471 which addresses the JDBC doclint errors

The webrev can be found at http://cr.openjdk.java.net/~lancea/8017471/webrev.00/

please note that for the WebRowset changes, you will need to use the udiff vs the sdiff formant as webrev generates errors due to the number of changes:


----------------------
src/share/classes/javax/sql/rowset/WebRowSet.java
		 patch cdiffs udiffs/usr/bin/awk: limited to 50 pat,pat statements at source line 74 source file /tmp/64799.file1
 context is
	NR==374,NR==377 >>> 	{changed();next} <<< 
/usr/bin/awk: limited to 50 pat,pat statements at source line 75 source file /tmp/64799.file1
/usr/bin/awk: limited to 50 pat,pat statements at source line 76 source file /tmp/64799.file1
/usr/bin/awk: limited to 50 pat,pat statements at source line 75 source file /tmp/64799.file2
----------------------


Best
Lance





Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From kumar.x.srinivasan at oracle.com  Thu Jun 27 17:04:25 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 27 Jun 2013 10:04:25 -0700
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
In-Reply-To: <51C34E6D.4000502@oracle.com>
References: <51C34E6D.4000502@oracle.com>
Message-ID: <51CC7099.2050007@oracle.com>

Hi Sherman,

I started looking at this, my initial comment, the Unpacker.unpack
does not close its output and  we allow multiple pack  files to be 
concatenated,
I am assuming out.finish() will allow further jar files to be appended ?
or would this cause a problem ?

Kumar

> Hi,
>
> The zip time related changes[1] I pushed back last month appears
> to have the compatibility risk of breaking existing code. The main
> idea in that changeset is to use the more accurate and timezone
> insensitive utc time stored in the extra field for the 
> ZipEntry.set/getTime()
> if possible. However it turns out the reality is that the code out there
> might have already had some interesting workaround/hack solution
> to workaround the problem that the time stamp stored in the "standard'
> zip entry header is a MS-DOS standard date/time, which is a "local
> date/time" and sensitive to timezone, in which, if the zip is archived
> in time zone A (our implementation converts the "java" time to dos
> time by using the default tz A) and then transferred/un-archived in
> a different zone B (use default tz B to convert back to java time), we
> have a time stamp mess up. The "workaround" from pack200 for this
> issue when pack/unpacking a jar file is to "specify/recommend/suggest"
> in its spec that the "time zone" in a jar file entry is assumed to be 
> "UTC",
> so the pack/unpack200 implementation set the "default time" to utc
> before the pack/unpack and set it back to the original after that. It 
> worked
> "perfectly" for a roundtrip pack/unpacking, until the changeset [2], in
> which ZipEntry.getTime() (packing) returns a real utc time and the 
> following
> ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time
> entry, this is the root cause of this regression.
>
> Given the facts that
> (1) there are actually two real physical time stamps in a zip file 
> header,
> one is in the date/time fields, which is MS-DOS-local-date/time-with-2-
> seconds-granularity , one is in the extra data field, which is 
> UTC-1-second
> -granularity
> (2) and there are applications over there that have dependency on the
> MS-DOS date/time stamp.
>
> I'm proposing the following approach to add the functionality of 
> supporting
> the "utc-date/time-with-1-second granularity" and keep the old behavior
> of the get/setTime() of the ZipEntry.
>
> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
>      To set via the old setTime() will only store the time into zip's 
> standard
>      date/time field, which is in MS-DOS date/time. And getTime() only 
> returns
>      the date/time from that field, when read from the zip file/stream.
> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>      and the last modified time set via the new method will also set 
> the "time",
>      and the getLastModifiedTime() also returns the "time", if the UTC 
> time
>      stamp fields are not set in the zip file header. The idea is that 
> for the new
>      application, the recommendation is to use 
> ZipEntry.set/getLastModifiedTime()
>      for better/correct time stamp, but the existing apps keep the 
> same behavior.
> (3) jar and ZipOutputStream are updated to use the 
> set/getLastModifiedTime().
> (4) Pack/unpack continues to use the set/getTime(), so the current 
> workaround
>      continues work. I will leave this to Kuma to decide how it should 
> be handled
>      going forward. (there are two facts need to be considered here, 
> a) the
>      existing jar file might not have the utc time instored, and b) 
> all "extra" data
>      are wiped out during the pack/unpacking process)
> (5) additionally add another pair of atime/get/setLastAccessTime and
>      ctime/get/setCreationTime().
> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the 
> "new"
>      nio FileTime, instead of the "long". This may add some additional 
> cost of
>      conversion when working with them, but may also help improve the
>      performance if the time stamps are directly from nio  file system 
> when
>      get/set XYZTime. Good/bad?
>
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>
> Comment, option and suggestion are appreciated.
>
> -Sherman
>
> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f



From jonathan.gibbons at oracle.com  Thu Jun 27 17:12:03 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 27 Jun 2013 10:12:03 -0700
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51CC6B96.8080607@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51CC6B96.8080607@oracle.com>
Message-ID: <51CC7263.3070901@oracle.com>

Yes, I think that this is the correct approach.

-- Jon


On 06/27/2013 09:43 AM, Kumar Srinivasan wrote:
> If this is to be undone after the correct zip fix, why not add the 
> @ignore for now ?
> and enable this when 8015666 is fixed correctly.
>
> Kumar
>
>> This is fine to be a workaround for the test case for now. It 
>> probably will need to be
>> undo-ed after the propose change for #8015666 get integrated.
>>
>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>
>> The proposal for #8015666 is to keep the "existing" behavior of 
>> ZipEntry.getTime()
>> to return a LastModifiedTime converted from the zip entry's 
>> ms-dos-formatted date/time
>> field by using the "default" timezone. A new pair 
>> ZipEntry.get/setLastModifiedTime()
>> will be added to access the "real" UTC time stored in the zip entry, 
>> if presents.
>>
>> The API doc will be updated accordingly as well to explicitly explain 
>> the source of the
>> date/time and the its timezone sensitive conversion.
>>
>> -Sherman
>>
>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>> Hello,
>>>
>>> Please review this simple patch which updates regression test
>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>
>>> Please note that this patch is intended to address the test failures,
>>> and that I will be immediately opening a new bug to investigate and
>>> address deeper issues, and also to properly document the API.
>>>
>>> The webrev is here:
>>> http://cr.openjdk.java.net/~emc/8016760/
>>>
>>> The bug report is here:
>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>
>>> Thanks,
>>> Eric
>>
>



From xueming.shen at oracle.com  Thu Jun 27 17:12:49 2013
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 27 Jun 2013 10:12:49 -0700
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
In-Reply-To: <51CC7099.2050007@oracle.com>
References: <51C34E6D.4000502@oracle.com> <51CC7099.2050007@oracle.com>
Message-ID: <51CC7291.1080602@oracle.com>

On 06/27/2013 10:04 AM, Kumar Srinivasan wrote:
> Hi Sherman,
>
> I started looking at this, my initial comment, the Unpacker.unpack
> does not close its output and  we allow multiple pack  files to be concatenated,
> I am assuming out.finish() will allow further jar files to be appended ?
> or would this cause a problem ?

No, out.finish() will not allow further entry appending.  Then, it appears
we need to have a different approach to "finish" the Jar/ZipOutputStream.
What need to be done here is that either out.close/finish() need to be
invoked under the UTC locale as well (to output the time stamps in cen
table correctly).  This is another "incompatible" change of the previous
change, in which the msdosTime<->javaTime conversion no longer
occurs during the ZipEntry.set/getTime(), but during the read and write
the ZipEntry from/to the zip file.

-Sherman


>
> Kumar
>
>> Hi,
>>
>> The zip time related changes[1] I pushed back last month appears
>> to have the compatibility risk of breaking existing code. The main
>> idea in that changeset is to use the more accurate and timezone
>> insensitive utc time stored in the extra field for the ZipEntry.set/getTime()
>> if possible. However it turns out the reality is that the code out there
>> might have already had some interesting workaround/hack solution
>> to workaround the problem that the time stamp stored in the "standard'
>> zip entry header is a MS-DOS standard date/time, which is a "local
>> date/time" and sensitive to timezone, in which, if the zip is archived
>> in time zone A (our implementation converts the "java" time to dos
>> time by using the default tz A) and then transferred/un-archived in
>> a different zone B (use default tz B to convert back to java time), we
>> have a time stamp mess up. The "workaround" from pack200 for this
>> issue when pack/unpacking a jar file is to "specify/recommend/suggest"
>> in its spec that the "time zone" in a jar file entry is assumed to be "UTC",
>> so the pack/unpack200 implementation set the "default time" to utc
>> before the pack/unpack and set it back to the original after that. It worked
>> "perfectly" for a roundtrip pack/unpacking, until the changeset [2], in
>> which ZipEntry.getTime() (packing) returns a real utc time and the following
>> ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time
>> entry, this is the root cause of this regression.
>>
>> Given the facts that
>> (1) there are actually two real physical time stamps in a zip file header,
>> one is in the date/time fields, which is MS-DOS-local-date/time-with-2-
>> seconds-granularity , one is in the extra data field, which is UTC-1-second
>> -granularity
>> (2) and there are applications over there that have dependency on the
>> MS-DOS date/time stamp.
>>
>> I'm proposing the following approach to add the functionality of supporting
>> the "utc-date/time-with-1-second granularity" and keep the old behavior
>> of the get/setTime() of the ZipEntry.
>>
>> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
>>      To set via the old setTime() will only store the time into zip's standard
>>      date/time field, which is in MS-DOS date/time. And getTime() only returns
>>      the date/time from that field, when read from the zip file/stream.
>> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>>      and the last modified time set via the new method will also set the "time",
>>      and the getLastModifiedTime() also returns the "time", if the UTC time
>>      stamp fields are not set in the zip file header. The idea is that for the new
>>      application, the recommendation is to use ZipEntry.set/getLastModifiedTime()
>>      for better/correct time stamp, but the existing apps keep the same behavior.
>> (3) jar and ZipOutputStream are updated to use the set/getLastModifiedTime().
>> (4) Pack/unpack continues to use the set/getTime(), so the current workaround
>>      continues work. I will leave this to Kuma to decide how it should be handled
>>      going forward. (there are two facts need to be considered here, a) the
>>      existing jar file might not have the utc time instored, and b) all "extra" data
>>      are wiped out during the pack/unpacking process)
>> (5) additionally add another pair of atime/get/setLastAccessTime and
>>      ctime/get/setCreationTime().
>> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the "new"
>>      nio FileTime, instead of the "long". This may add some additional cost of
>>      conversion when working with them, but may also help improve the
>>      performance if the time stamps are directly from nio  file system when
>>      get/set XYZTime. Good/bad?
>>
>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>
>> Comment, option and suggestion are appreciated.
>>
>> -Sherman
>>
>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f
>



From joe.darcy at oracle.com  Thu Jun 27 17:15:22 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 10:15:22 -0700
Subject: review request for bug: 8017471 clean up of JDBC doclint errors
In-Reply-To: 
References: 
Message-ID: <51CC732A.1090901@oracle.com>

Hi Lance,

I looked through the patch and it looks fine; thanks,

-Joe

On 06/27/2013 09:56 AM, Lance Andersen wrote:
> Hi all,
>
> Need a reviewer for 8017471 which addresses the JDBC doclint errors
>
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8017471/webrev.00/
>
> please note that for the WebRowset changes, you will need to use the udiff vs the sdiff formant as webrev generates errors due to the number of changes:
>
>
> ----------------------
> src/share/classes/javax/sql/rowset/WebRowSet.java
> 		 patch cdiffs udiffs/usr/bin/awk: limited to 50 pat,pat statements at source line 74 source file /tmp/64799.file1
>   context is
> 	NR==374,NR==377 >>> 	{changed();next} <<<
> /usr/bin/awk: limited to 50 pat,pat statements at source line 75 source file /tmp/64799.file1
> /usr/bin/awk: limited to 50 pat,pat statements at source line 76 source file /tmp/64799.file1
> /usr/bin/awk: limited to 50 pat,pat statements at source line 75 source file /tmp/64799.file2
> ----------------------
>
>
> Best
> Lance
>
>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>



From joe.darcy at oracle.com  Thu Jun 27 17:59:24 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 10:59:24 -0700
Subject: JDK 8 request for review: doclint cleanup of java.util.prefs
Message-ID: <51CC7D7C.8070300@oracle.com>

Hello,

Please review the patch below which resolves doclint warnings in 
java.util.prefs.

Thanks,

-Joe

diff -r 4e69a7dfbeac 
src/share/classes/java/util/prefs/AbstractPreferences.java
--- a/src/share/classes/java/util/prefs/AbstractPreferences.java  Thu 
Jun 27 10:21:22 2013 +0100
+++ b/src/share/classes/java/util/prefs/AbstractPreferences.java  Thu 
Jun 27 10:57:21 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -1121,6 +1121,8 @@
       * removed.  (The implementor needn't check for any of these things.)
       *
       * 
    This method is invoked with the lock on this node held.
+     * @param key the key
+     * @param value the value
       */
      protected abstract void putSpi(String key, String value);

@@ -1139,6 +1141,7 @@
       *
       * 
    This method is invoked with the lock on this node held.
       *
+     * @param key the key
       * @return the value associated with the specified key at this 
preference
       *          node, or null if there is no association for this
       *          key, or the association cannot be determined at this time.
@@ -1152,6 +1155,7 @@
       * (The implementor needn't check for either of these things.)
       *
       * 
    This method is invoked with the lock on this node held.
+     * @param key the key
       */
      protected abstract void removeSpi(String key);

diff -r 4e69a7dfbeac 
src/share/classes/java/util/prefs/PreferencesFactory.java
--- a/src/share/classes/java/util/prefs/PreferencesFactory.java  Thu Jun 
27 10:21:22 2013 +0100
+++ b/src/share/classes/java/util/prefs/PreferencesFactory.java  Thu Jun 
27 10:57:21 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2005, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -45,6 +45,7 @@
      /**
       * Returns the system root preference node.  (Multiple calls on this
       * method will return the same object reference.)
+     * @return the system root preference node
       */
      Preferences systemRoot();

@@ -52,6 +53,8 @@
       * Returns the user root preference node corresponding to the calling
       * user.  In a server, the returned value will typically depend on
       * some implicit client-context.
+     * @return the user root preference node corresponding to the calling
+     * user
       */
      Preferences userRoot();
  }



From Lance.Andersen at oracle.com  Thu Jun 27 18:01:44 2013
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Thu, 27 Jun 2013 14:01:44 -0400
Subject: JDK 8 request for review: doclint cleanup of java.util.prefs
In-Reply-To: <51CC7D7C.8070300@oracle.com>
References: <51CC7D7C.8070300@oracle.com>
Message-ID: 

+1
On Jun 27, 2013, at 1:59 PM, Joe Darcy  wrote:

> Hello,
> 
> Please review the patch below which resolves doclint warnings in java.util.prefs.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 4e69a7dfbeac src/share/classes/java/util/prefs/AbstractPreferences.java
> --- a/src/share/classes/java/util/prefs/AbstractPreferences.java  Thu Jun 27 10:21:22 2013 +0100
> +++ b/src/share/classes/java/util/prefs/AbstractPreferences.java  Thu Jun 27 10:57:21 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -1121,6 +1121,8 @@
>      * removed.  (The implementor needn't check for any of these things.)
>      *
>      * 
    This method is invoked with the lock on this node held.
> +     * @param key the key
> +     * @param value the value
>      */
>     protected abstract void putSpi(String key, String value);
> 
> @@ -1139,6 +1141,7 @@
>      *
>      * 
    This method is invoked with the lock on this node held.
>      *
> +     * @param key the key
>      * @return the value associated with the specified key at this preference
>      *          node, or null if there is no association for this
>      *          key, or the association cannot be determined at this time.
> @@ -1152,6 +1155,7 @@
>      * (The implementor needn't check for either of these things.)
>      *
>      * 
    This method is invoked with the lock on this node held.
> +     * @param key the key
>      */
>     protected abstract void removeSpi(String key);
> 
> diff -r 4e69a7dfbeac src/share/classes/java/util/prefs/PreferencesFactory.java
> --- a/src/share/classes/java/util/prefs/PreferencesFactory.java  Thu Jun 27 10:21:22 2013 +0100
> +++ b/src/share/classes/java/util/prefs/PreferencesFactory.java  Thu Jun 27 10:57:21 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2005, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -45,6 +45,7 @@
>     /**
>      * Returns the system root preference node.  (Multiple calls on this
>      * method will return the same object reference.)
> +     * @return the system root preference node
>      */
>     Preferences systemRoot();
> 
> @@ -52,6 +53,8 @@
>      * Returns the user root preference node corresponding to the calling
>      * user.  In a server, the returned value will typically depend on
>      * some implicit client-context.
> +     * @return the user root preference node corresponding to the calling
> +     * user
>      */
>     Preferences userRoot();
> }
> 




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From joe.darcy at oracle.com  Thu Jun 27 18:07:04 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 18:07:04 +0000
Subject: hg: jdk8/tl/jdk: 8019304: Fix doclint issues in java.util.prefs
Message-ID: <20130627180740.9284B485CF@hg.openjdk.java.net>

Changeset: 1c31082f0a51
Author:    darcy
Date:      2013-06-27 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c31082f0a51

8019304: Fix doclint issues in java.util.prefs
Reviewed-by: lancea

! src/share/classes/java/util/prefs/AbstractPreferences.java
! src/share/classes/java/util/prefs/PreferencesFactory.java



From eric.mccorkle at oracle.com  Thu Jun 27 18:10:18 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 27 Jun 2013 14:10:18 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51CC76E0.8060104@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51CC6B96.8080607@oracle.com> <51CC7263.3070901@oracle.com>
	<51CC76E0.8060104@oracle.com>
Message-ID: <51CC800A.30000@oracle.com>

Accidentally dropped core-libs-dev from the reply.

On 06/27/13 13:31, Eric McCorkle wrote:
> I could easily replace the patch I have now with one that just marks the
> test @ignore and commit it.  Do we want to go ahead and approve that?
> 
> On 06/27/13 13:12, Jonathan Gibbons wrote:
>> Yes, I think that this is the correct approach.
>>
>> -- Jon
>>
>>
>> On 06/27/2013 09:43 AM, Kumar Srinivasan wrote:
>>> If this is to be undone after the correct zip fix, why not add the
>>> @ignore for now ?
>>> and enable this when 8015666 is fixed correctly.
>>>
>>> Kumar
>>>
>>>> This is fine to be a workaround for the test case for now. It
>>>> probably will need to be
>>>> undo-ed after the propose change for #8015666 get integrated.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>>
>>>> The proposal for #8015666 is to keep the "existing" behavior of
>>>> ZipEntry.getTime()
>>>> to return a LastModifiedTime converted from the zip entry's
>>>> ms-dos-formatted date/time
>>>> field by using the "default" timezone. A new pair
>>>> ZipEntry.get/setLastModifiedTime()
>>>> will be added to access the "real" UTC time stored in the zip entry,
>>>> if presents.
>>>>
>>>> The API doc will be updated accordingly as well to explicitly explain
>>>> the source of the
>>>> date/time and the its timezone sensitive conversion.
>>>>
>>>> -Sherman
>>>>
>>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this simple patch which updates regression test
>>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>>
>>>>> Please note that this patch is intended to address the test failures,
>>>>> and that I will be immediately opening a new bug to investigate and
>>>>> address deeper issues, and also to properly document the API.
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>>
>>>>> The bug report is here:
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>>
>>>>> Thanks,
>>>>> Eric
>>>>
>>>
>>

From Alan.Bateman at oracle.com  Thu Jun 27 18:12:46 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Jun 2013 19:12:46 +0100
Subject: JDK 8 request for review: doclint cleanup of java.util.prefs
In-Reply-To: <51CC7D7C.8070300@oracle.com>
References: <51CC7D7C.8070300@oracle.com>
Message-ID: <51CC809E.5040002@oracle.com>

On 27/06/2013 18:59, Joe Darcy wrote:
> Hello,
>
> Please review the patch below which resolves doclint warnings in 
> java.util.prefs.
>
> Thanks,
>
> -Joe
This looks okay to me although you might want to put in a blank line 
before the @param list so that is consistent with the other prefs classes.

-Alan.


From brian.burkhalter at oracle.com  Thu Jun 27 18:27:20 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 27 Jun 2013 11:27:20 -0700
Subject: RFC: 6178739 - Formatter - Zero padding flag with zero width
In-Reply-To: <518390B2-C0E1-43A9-8BD8-68211414C633@oracle.com>
References: <9F125A40-BC04-4B1D-B6D0-A45B6B673314@oracle.com>
	<51C91BCB.70707@oracle.com>
	
	<51CB18DA.5010402@oracle.com>
	<9C41A7A3-F1D4-410D-ADAB-54B94C46F419@oracle.com>
	<518390B2-C0E1-43A9-8BD8-68211414C633@oracle.com>
Message-ID: <715B476F-E7AA-4229-B03B-6257223489D9@oracle.com>


On Jun 26, 2013, at 10:55 PM, David DeHaven wrote:

>>> Specifically, I was referred to how C handles "%0.4f\n".
> 
> No width, decimal truncated (rounded? floored? I forgot which it is) to four digits.
> 
> -DrD-
> 
>>>   printf("%0.4f\n", 56789.456789F);
> ...
>>> 56789.4570
>>  ^ ^ ^ ^ ^ ^ ^ ^
> ...
>> "A leading zero in the width value is interpreted as the zero-padding flag mentioned above [?]."
> 
> Only if there's a valid width following, which there isn't in the case above. Try "%016.4" with the above test. Note that the width is the *full* width of the entire field, including decimal point and following digits.
> 
> printf("%016.4f\n", 56789.456789F);
> printf("%0.4f\n", 56789.456789F);
> 
> Produces:
> 00000056789.4570
> 56789.4570

    printf("%016.4f\n", 56789.456789F);
    printf("%1.4f\n", 56789.456789F);
    printf("%0.4f\n", 56789.456789F);

produces (on Mac OS X)

00000056789.4570
56789.4570
56789.4570

whereas

        System.out.printf("%016.4f\n", 56789.456789);
        System.out.printf("%1.4f\n", 56789.456789);
        System.out.printf("%0.4f\n", 56789.456789);

produces

00000056789.4568
56789.4568
Exception in thread "main" java.util.MissingFormatWidthException: %0.4f

Two possible solutions are:

1) Change the specification of the width field to

"The optional width is a positive decimal integer indicating the minimum
number of characters to be written to the output. A leading zero in the width
value is interpreted to be the zero-padding flag discussed below."

2) Handle a 0.x as indicating zero width, not zero padding.

Brian

From brian.burkhalter at oracle.com  Thu Jun 27 18:29:01 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 27 Jun 2013 11:29:01 -0700
Subject: RFR 8017540: Improve multi-threaded contention behavior of
	BigInteger.toString() radix conversion cache
In-Reply-To: <51CC1F6A.4010108@oracle.com>
References: 
	<51C9577C.4000301@oracle.com>
	
	<51C9EBA5.4020002@oracle.com>
	
	<51C9F537.1050002@oracle.com>
	
	<8B7666A8-8864-416A-BC6D-2284AC29BC7D@oracle.com>
	
	<604A3175-3ABA-4BD2-9283-067534301489@oracle.com>
	
	<51CBDDA8.4000107@gmail.com> <51CC1F6A.4010108@oracle.com>
Message-ID: <3FEB9B7E-E8A4-4F93-9FC9-F82130CF30D3@oracle.com>

On Jun 27, 2013, at 4:18 AM, Aleksey Shipilev wrote:

> On 06/27/2013 10:37 AM, Peter Levart wrote:
>> Hi,
>> 
>> This version seems correct. Maybe just replace double volatile read at
>> length re-check with a single one:
>> 
>>    private static BigInteger getRadixConversionCache(int radix, int
>> exponent) {
>>        BigInteger[] cacheLine = powerCache[radix]; // volatile read
>>        if (exponent < cacheLine.length)
>>            return cacheLine[exponent];
>> 
>>        int oldLength = cacheLine.length;
>>        cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
>>        for (int i = oldLength; i <= exponent; i++)
>>            cacheLine[i] = cacheLine[i - 1].pow(2);
>> 
>>        BigInteger[][] pc = powerCache; // volatile read again
>>        if (exponent >= pc[radix].length) {
>>            pc = pc.clone();
>>            pc[radix] = cacheLine;
>>            powerCache = pc; // volatile write, publish
>>        }
>>        return cacheLine[exponent];
>>    }
>> 
> 
> Yes, I'm voting for this one. All other improvements Peter had
> suggested, while interesting, seem to not to worth the trouble.

Are there any objections to this version (as included above)?

Brian

From joe.darcy at oracle.com  Thu Jun 27 18:49:08 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 18:49:08 +0000
Subject: hg: jdk8/tl/langtools: 8019308: Add descriptions of Java SE 7 and 8
	language changes to SourceVersion
Message-ID: <20130627184914.3D2B9485D0@hg.openjdk.java.net>

Changeset: 065f8cb7bd89
Author:    darcy
Date:      2013-06-27 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/065f8cb7bd89

8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion
Reviewed-by: jjg

! src/share/classes/javax/lang/model/SourceVersion.java



From joe.darcy at oracle.com  Thu Jun 27 18:58:38 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 11:58:38 -0700
Subject: JDK 8 code review request: doclint cleanup of java.util.logging
Message-ID: <51CC8B5E.1040203@oracle.com>

Hello,

Please review the patch below which resolves doclint warnings in 
java.util.logging.

Thanks,

-Joe

diff -r 1c31082f0a51 src/share/classes/java/util/logging/Handler.java
--- a/src/share/classes/java/util/logging/Handler.java    Thu Jun 27 
11:06:46 2013 -0700
+++ b/src/share/classes/java/util/logging/Handler.java    Thu Jun 27 
11:56:23 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -209,6 +209,7 @@
      /**
       * Retrieves the ErrorManager for this Handler.
       *
+     * @return the ErrorManager for this Handler
       * @exception  SecurityException  if a security manager exists and if
       *             the caller does not have 
LoggingPermission("control").
       */
diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogManager.java
--- a/src/share/classes/java/util/logging/LogManager.java    Thu Jun 27 
11:06:46 2013 -0700
+++ b/src/share/classes/java/util/logging/LogManager.java    Thu Jun 27 
11:56:23 2013 -0700
@@ -257,7 +257,8 @@
      }

      /**
-     * Return the global LogManager object.
+     * Returns the global LogManager object.
+     * @return the global LogManager object
       */
      public static LogManager getLogManager() {
          if (manager != null) {
diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogRecord.java
--- a/src/share/classes/java/util/logging/LogRecord.java    Thu Jun 27 
11:06:46 2013 -0700
+++ b/src/share/classes/java/util/logging/LogRecord.java    Thu Jun 27 
11:56:23 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -211,6 +211,7 @@
       * the message string before formatting it.  The result may
       * be null if the message is not localizable, or if no suitable
       * ResourceBundle is available.
+     * @return the localization resource bundle
       */
      public ResourceBundle getResourceBundle() {
          return resourceBundle;
@@ -231,6 +232,7 @@
       * This is the name for the ResourceBundle that should be
       * used to localize the message string before formatting it.
       * The result may be null if the message is not localizable.
+     * @return the localization resource bundle name
       */
      public String getResourceBundleName() {
          return resourceBundleName;
@@ -281,6 +283,7 @@
       * 
    
       * Sequence numbers are normally assigned in the LogRecord 
constructor,
       * so it should not normally be necessary to use this method.
+     * @param seq the sequence number
       */
      public void setSequenceNumber(long seq) {
          sequenceNumber = seq;



From bradford.wetmore at oracle.com  Thu Jun 27 19:08:41 2013
From: bradford.wetmore at oracle.com (Brad Wetmore)
Date: Thu, 27 Jun 2013 12:08:41 -0700
Subject: Review Request: JDK-8019227: JDK-8010325 broke the old build
In-Reply-To: <51CBD813.6080807@oracle.com>
References: <51CBC1A7.5020206@oracle.com> <51CBD813.6080807@oracle.com>
Message-ID: <51CC8DB9.8050406@oracle.com>


> The old build has not produced usable bits for several months, it may
> not have been failing but if you look closely (or run the tests) then
> you'll see that there are several things missing. On build-dev then
> you'll probably have seen a mail or two from me where I was trying to
> encourage the build group to set a date to finally retire and remove the
> old build - this is because the old build is just a tax on every change
> that needs to touch the build.
>
> Anyway, the change looks okay but I strongly encourage you to put in the
> time to resolve the usability or others ssues that arise when working on
> JCE.

Alan, I tried to save you the effort of composing just such a reply. 
I've seen your mails and agree with your sentiment.  You are preaching 
to the choir [1].  ;)

Thank you Chris, for doing the operation!

Brad

[1] http://idioms.thefreedictionary.com/preach+to+the+choir


From lance.andersen at oracle.com  Thu Jun 27 19:08:28 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Thu, 27 Jun 2013 19:08:28 +0000
Subject: hg: jdk8/tl/jdk: 8017471: Fix JDBC -Xdoclint public errors
Message-ID: <20130627190852.57175485D2@hg.openjdk.java.net>

Changeset: b9ba04dc210f
Author:    lancea
Date:      2013-06-27 15:07 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9ba04dc210f

8017471: Fix JDBC -Xdoclint public errors
Reviewed-by: darcy

! src/share/classes/java/sql/Blob.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Clob.java
! src/share/classes/java/sql/DatabaseMetaData.java
! src/share/classes/java/sql/Driver.java
! src/share/classes/java/sql/DriverAction.java
! src/share/classes/java/sql/NClob.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/java/sql/SQLInput.java
! src/share/classes/java/sql/SQLPermission.java
! src/share/classes/java/sql/SQLXML.java
! src/share/classes/java/sql/Wrapper.java
! src/share/classes/javax/sql/CommonDataSource.java
! src/share/classes/javax/sql/ConnectionPoolDataSource.java
! src/share/classes/javax/sql/DataSource.java
! src/share/classes/javax/sql/RowSet.java
! src/share/classes/javax/sql/XADataSource.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/CachedRowSet.java
! src/share/classes/javax/sql/rowset/FilteredRowSet.java
! src/share/classes/javax/sql/rowset/JdbcRowSet.java
! src/share/classes/javax/sql/rowset/Joinable.java
! src/share/classes/javax/sql/rowset/Predicate.java
! src/share/classes/javax/sql/rowset/RowSetProvider.java
! src/share/classes/javax/sql/rowset/RowSetWarning.java
! src/share/classes/javax/sql/rowset/WebRowSet.java
! src/share/classes/javax/sql/rowset/package.html
! src/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/share/classes/javax/sql/rowset/serial/SerialClob.java
! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java
! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java
! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
! src/share/classes/javax/sql/rowset/spi/SyncResolver.java



From Lance.Andersen at oracle.com  Thu Jun 27 19:16:35 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 27 Jun 2013 15:16:35 -0400
Subject: JDK 8 code review request: doclint cleanup of java.util.logging
In-Reply-To: <51CC8B5E.1040203@oracle.com>
References: <51CC8B5E.1040203@oracle.com>
Message-ID: <4CE7243E-D983-4C6D-8D40-ADAFD589E004@oracle.com>

+1
On Jun 27, 2013, at 2:58 PM, Joe Darcy wrote:

> Hello,
> 
> Please review the patch below which resolves doclint warnings in java.util.logging.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 1c31082f0a51 src/share/classes/java/util/logging/Handler.java
> --- a/src/share/classes/java/util/logging/Handler.java    Thu Jun 27 11:06:46 2013 -0700
> +++ b/src/share/classes/java/util/logging/Handler.java    Thu Jun 27 11:56:23 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -209,6 +209,7 @@
>     /**
>      * Retrieves the ErrorManager for this Handler.
>      *
> +     * @return the ErrorManager for this Handler
>      * @exception  SecurityException  if a security manager exists and if
>      *             the caller does not have LoggingPermission("control").
>      */
> diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogManager.java
> --- a/src/share/classes/java/util/logging/LogManager.java    Thu Jun 27 11:06:46 2013 -0700
> +++ b/src/share/classes/java/util/logging/LogManager.java    Thu Jun 27 11:56:23 2013 -0700
> @@ -257,7 +257,8 @@
>     }
> 
>     /**
> -     * Return the global LogManager object.
> +     * Returns the global LogManager object.
> +     * @return the global LogManager object
>      */
>     public static LogManager getLogManager() {
>         if (manager != null) {
> diff -r 1c31082f0a51 src/share/classes/java/util/logging/LogRecord.java
> --- a/src/share/classes/java/util/logging/LogRecord.java    Thu Jun 27 11:06:46 2013 -0700
> +++ b/src/share/classes/java/util/logging/LogRecord.java    Thu Jun 27 11:56:23 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -211,6 +211,7 @@
>      * the message string before formatting it.  The result may
>      * be null if the message is not localizable, or if no suitable
>      * ResourceBundle is available.
> +     * @return the localization resource bundle
>      */
>     public ResourceBundle getResourceBundle() {
>         return resourceBundle;
> @@ -231,6 +232,7 @@
>      * This is the name for the ResourceBundle that should be
>      * used to localize the message string before formatting it.
>      * The result may be null if the message is not localizable.
> +     * @return the localization resource bundle name
>      */
>     public String getResourceBundleName() {
>         return resourceBundleName;
> @@ -281,6 +283,7 @@
>      * 
    
>      * Sequence numbers are normally assigned in the LogRecord constructor,
>      * so it should not normally be necessary to use this method.
> +     * @param seq the sequence number
>      */
>     public void setSequenceNumber(long seq) {
>         sequenceNumber = seq;
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From joe.darcy at oracle.com  Thu Jun 27 19:24:39 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 19:24:39 +0000
Subject: hg: jdk8/tl/jdk: 8019315: Fix doclint issues in java.util.logging
Message-ID: <20130627192500.9C6BA485D3@hg.openjdk.java.net>

Changeset: b8f16cb2d95b
Author:    darcy
Date:      2013-06-27 12:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8f16cb2d95b

8019315: Fix doclint issues in java.util.logging
Reviewed-by: lancea

! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/LogRecord.java



From kumar.x.srinivasan at oracle.com  Thu Jun 27 19:43:51 2013
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Thu, 27 Jun 2013 19:43:51 +0000
Subject: hg: jdk8/tl/langtools: 7080001: Need to bump version numbers in
	build.properties for 8
Message-ID: <20130627194356.CCBFF485D6@hg.openjdk.java.net>

Changeset: 97e798c06804
Author:    ksrini
Date:      2013-06-27 12:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97e798c06804

7080001: Need to bump version numbers in build.properties for 8
Reviewed-by: jjg

! make/build.properties



From joe.darcy at oracle.com  Thu Jun 27 19:47:42 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 12:47:42 -0700
Subject: JDK 8 core review request for doclint warnings in javax.script
Message-ID: <51CC96DE.3010307@oracle.com>

Hello,

Please review the next patch in a series of patches to resolve doclint 
warnings in the JDK; this time in javax.script.

Thanks,

-Joe

diff -r b8f16cb2d95b src/share/classes/javax/script/Invocable.java
--- a/src/share/classes/javax/script/Invocable.java    Thu Jun 27 
12:24:26 2013 -0700
+++ b/src/share/classes/javax/script/Invocable.java    Thu Jun 27 
12:45:29 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -63,6 +63,7 @@
      /**
       * Used to call top-level procedures and functions defined in scripts.
       *
+     * @param name of the procedure or function to call
       * @param args Arguments to pass to the procedure or function
       * @return The value returned by the procedure or function
       *
@@ -79,6 +80,7 @@
       * the interpreter. The methods of the interface
       * may be implemented using the invokeFunction method.
       *
+     * @param  the type of the interface to return
       * @param clasz The Class object of the interface to 
return.
       *
       * @return An instance of requested interface - null if the 
requested interface is unavailable,
@@ -95,6 +97,7 @@
       * a scripting object compiled in the interpreter. The methods of the
       * interface may be implemented using the 
invokeMethod method.
       *
+     * @param  the type of the interface to return
       * @param thiz The scripting object whose member functions are 
used to implement the methods of the interface.
       * @param clasz The Class object of the interface to 
return.
       *
diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptContext.java
--- a/src/share/classes/javax/script/ScriptContext.java    Thu Jun 27 
12:24:26 2013 -0700
+++ b/src/share/classes/javax/script/ScriptContext.java    Thu Jun 27 
12:45:29 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -78,6 +78,7 @@
       * @return The associated Bindings. Returns 
null if it has not
       * been set.
       *
+     * @param scope The scope
       * @throws IllegalArgumentException If no Bindings is 
defined for the
       * specified scope value in ScriptContext of this type.
       */
diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptEngineFactory.java
--- a/src/share/classes/javax/script/ScriptEngineFactory.java    Thu Jun 
27 12:24:26 2013 -0700
+++ b/src/share/classes/javax/script/ScriptEngineFactory.java    Thu Jun 
27 12:45:29 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -80,6 +80,7 @@
       * identify the ScriptEngine by the 
ScriptEngineManager.
       * For instance, an implementation based on the Mozilla Rhino 
Javascript engine might
       * return list containing {"javascript", "rhino"}.
+     * @return an immutable list of short names
       */
      public List getNames();

diff -r b8f16cb2d95b src/share/classes/javax/script/SimpleScriptContext.java
--- a/src/share/classes/javax/script/SimpleScriptContext.java    Thu Jun 
27 12:24:26 2013 -0700
+++ b/src/share/classes/javax/script/SimpleScriptContext.java    Thu Jun 
27 12:45:29 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -82,7 +82,9 @@
       */
      protected Bindings globalScope;

-
+    /**
+     * Create a {@code SimpleScriptContext}.
+     */
      public SimpleScriptContext() {
          engineScope = new SimpleBindings();
          globalScope = null;



From Lance.Andersen at oracle.com  Thu Jun 27 19:49:48 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 27 Jun 2013 15:49:48 -0400
Subject: JDK 8 core review request for doclint warnings in javax.script
In-Reply-To: <51CC96DE.3010307@oracle.com>
References: <51CC96DE.3010307@oracle.com>
Message-ID: 

looks fine joe
On Jun 27, 2013, at 3:47 PM, Joe Darcy wrote:

> Hello,
> 
> Please review the next patch in a series of patches to resolve doclint warnings in the JDK; this time in javax.script.
> 
> Thanks,
> 
> -Joe
> 
> diff -r b8f16cb2d95b src/share/classes/javax/script/Invocable.java
> --- a/src/share/classes/javax/script/Invocable.java    Thu Jun 27 12:24:26 2013 -0700
> +++ b/src/share/classes/javax/script/Invocable.java    Thu Jun 27 12:45:29 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -63,6 +63,7 @@
>     /**
>      * Used to call top-level procedures and functions defined in scripts.
>      *
> +     * @param name of the procedure or function to call
>      * @param args Arguments to pass to the procedure or function
>      * @return The value returned by the procedure or function
>      *
> @@ -79,6 +80,7 @@
>      * the interpreter. The methods of the interface
>      * may be implemented using the invokeFunction method.
>      *
> +     * @param  the type of the interface to return
>      * @param clasz The Class object of the interface to return.
>      *
>      * @return An instance of requested interface - null if the requested interface is unavailable,
> @@ -95,6 +97,7 @@
>      * a scripting object compiled in the interpreter. The methods of the
>      * interface may be implemented using the invokeMethod method.
>      *
> +     * @param  the type of the interface to return
>      * @param thiz The scripting object whose member functions are used to implement the methods of the interface.
>      * @param clasz The Class object of the interface to return.
>      *
> diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptContext.java
> --- a/src/share/classes/javax/script/ScriptContext.java    Thu Jun 27 12:24:26 2013 -0700
> +++ b/src/share/classes/javax/script/ScriptContext.java    Thu Jun 27 12:45:29 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -78,6 +78,7 @@
>      * @return The associated Bindings. Returns null if it has not
>      * been set.
>      *
> +     * @param scope The scope
>      * @throws IllegalArgumentException If no Bindings is defined for the
>      * specified scope value in ScriptContext of this type.
>      */
> diff -r b8f16cb2d95b src/share/classes/javax/script/ScriptEngineFactory.java
> --- a/src/share/classes/javax/script/ScriptEngineFactory.java    Thu Jun 27 12:24:26 2013 -0700
> +++ b/src/share/classes/javax/script/ScriptEngineFactory.java    Thu Jun 27 12:45:29 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -80,6 +80,7 @@
>      * identify the ScriptEngine by the ScriptEngineManager.
>      * For instance, an implementation based on the Mozilla Rhino Javascript engine might
>      * return list containing {"javascript", "rhino"}.
> +     * @return an immutable list of short names
>      */
>     public List getNames();
> 
> diff -r b8f16cb2d95b src/share/classes/javax/script/SimpleScriptContext.java
> --- a/src/share/classes/javax/script/SimpleScriptContext.java    Thu Jun 27 12:24:26 2013 -0700
> +++ b/src/share/classes/javax/script/SimpleScriptContext.java    Thu Jun 27 12:45:29 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -82,7 +82,9 @@
>      */
>     protected Bindings globalScope;
> 
> -
> +    /**
> +     * Create a {@code SimpleScriptContext}.
> +     */
>     public SimpleScriptContext() {
>         engineScope = new SimpleBindings();
>         globalScope = null;
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From stuart.marks at oracle.com  Thu Jun 27 20:33:43 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 27 Jun 2013 20:33:43 +0000
Subject: hg: jdk8/tl/jdk: 8019224: add exception chaining to RMI CGIHandler
Message-ID: <20130627203423.81A92485D7@hg.openjdk.java.net>

Changeset: 6729f7ef94cd
Author:    smarks
Date:      2013-06-27 13:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6729f7ef94cd

8019224: add exception chaining to RMI CGIHandler
Reviewed-by: darcy

! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java



From forax at univ-mlv.fr  Thu Jun 27 20:58:42 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Jun 2013 22:58:42 +0200
Subject: hg: jdk8/tl/langtools: 8019308: Add descriptions of Java SE 7
	and 8 language changes to SourceVersion
In-Reply-To: <20130627184914.3D2B9485D0@hg.openjdk.java.net>
References: <20130627184914.3D2B9485D0@hg.openjdk.java.net>
Message-ID: <51CCA782.90902@univ-mlv.fr>

On 06/27/2013 08:49 PM, joe.darcy at oracle.com wrote:
> Changeset: 065f8cb7bd89
> Author:    darcy
> Date:      2013-06-27 11:46 -0700
> URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/065f8cb7bd89
>
> 8019308: Add descriptions of Java SE 7 and 8 language changes to SourceVersion
> Reviewed-by: jjg
>
> ! src/share/classes/javax/lang/model/SourceVersion.java
>

too late for this changeset, but I think that enhanced inference is also 
a feature of 8.

R?mi



From joe.darcy at oracle.com  Thu Jun 27 21:11:36 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 27 Jun 2013 21:11:36 +0000
Subject: hg: jdk8/tl/jdk: 8019320: Fix doclint issues in javax.script
Message-ID: <20130627211158.5E362485E4@hg.openjdk.java.net>

Changeset: 1099fe14fb65
Author:    darcy
Date:      2013-06-27 14:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1099fe14fb65

8019320: Fix doclint issues in javax.script
Reviewed-by: lancea

! src/share/classes/javax/script/Invocable.java
! src/share/classes/javax/script/ScriptContext.java
! src/share/classes/javax/script/ScriptEngineFactory.java
! src/share/classes/javax/script/SimpleScriptContext.java



From forax at univ-mlv.fr  Thu Jun 27 21:13:09 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 27 Jun 2013 23:13:09 +0200
Subject: Question on HashMap change in 8011200
In-Reply-To: <51CBF181.1020301@linux.vnet.ibm.com>
References: <51CBF181.1020301@linux.vnet.ibm.com>
Message-ID: <51CCAAE5.4010707@univ-mlv.fr>

On 06/27/2013 10:02 AM, Shi Jun Zhang wrote:
> Hi,
>
> There are some isEmpty() check added into get/remove methods since 
> 8011200 to return directly if HashMap is empty. However isEmpty is a 
> non-final public method which can be overridden by subclass. If the 
> subclass defines isEmpty differently from HashMap, it would cause 
> problem while getting or removing elements.

yes, it's a bug.
Could you report it ?

R?mi

>
> For example, here is a simple test case, the subclass of HashMap 
> always has at least one key value pair so isEmpty will never be false.
>
> /////////////////////////////////////////////////////////////////////////////// 
>
>
> import java.util.HashMap;
>
>
> public class HashMapTest {
>     public static class NotEmptyHashMap extends HashMap {
>         private K alwaysExistingKey;
>         private V alwaysExistingValue;
>
>         @Override
>         public V get(Object key) {
>             if (key == alwaysExistingKey) {
>                 return alwaysExistingValue;
>             }
>             return super.get(key);
>         }
>
>         @Override
>         public int size() {
>             return super.size() + 1;
>         }
>
>         @Override
>         public boolean isEmpty() {
>             return size() == 0;
>         }
>     }
>
>     public static void main(String[] args) {
>         NotEmptyHashMap map = new NotEmptyHashMap<>();
>         map.get("key");
>     }
> }
> ////////////////////////////////////////////////////////////////////////// 
>
>
> The test can end successfully before 8011200 but it will throw 
> ArrayIndexOutOfBoundsException after 8011200. The reason is isEmpty() 
> check in HashMap.getEntry() method gets passed but the actual table 
> length is 0. I think the real intention of isEmpty() check is to check 
> whether size in HashMap is 0 but not whether the subclass is empty, so 
> I suggest to use "size == 0" instead of "isEmpty()" in get/remove 
> methods.
>
> Do you think this is a bug or a wrong usage of extending HashMap? I 
> find there is a similar usage in javax.swing.MultiUIDefaults which 
> extends Hashtable.
>
>



From eric.mccorkle at oracle.com  Thu Jun 27 21:37:30 2013
From: eric.mccorkle at oracle.com (Eric McCorkle)
Date: Thu, 27 Jun 2013 17:37:30 -0400
Subject: Review request for JDK-8016760: failure of regression test
	langtools/tools/javac/T6725036.java
In-Reply-To: <51CC8208.90909@oracle.com>
References: <51C9A325.4020605@oracle.com> <51C9D85D.6080905@oracle.com>
	<51CC6B96.8080607@oracle.com> <51CC7263.3070901@oracle.com>
	<51CC76E0.8060104@oracle.com> <51CC8208.90909@oracle.com>
Message-ID: <51CCB09A.3080705@oracle.com>

Ok.  I will put it through shortly.

On 06/27/13 14:18, Jonathan Gibbons wrote:
> Yes,
> 
> Per the latest conventions, the line should be of the form
> 
> @ignore  BUGID: synopsis
> 
> where BUGID is the number for a currently open issue that justifies this
> test being ignored.
> 
> -- Jon
> 
> On 06/27/2013 10:31 AM, Eric McCorkle wrote:
>> I could easily replace the patch I have now with one that just marks the
>> test @ignore and commit it.  Do we want to go ahead and approve that?
>>
>> On 06/27/13 13:12, Jonathan Gibbons wrote:
>>> Yes, I think that this is the correct approach.
>>>
>>> -- Jon
>>>
>>>
>>> On 06/27/2013 09:43 AM, Kumar Srinivasan wrote:
>>>> If this is to be undone after the correct zip fix, why not add the
>>>> @ignore for now ?
>>>> and enable this when 8015666 is fixed correctly.
>>>>
>>>> Kumar
>>>>
>>>>> This is fine to be a workaround for the test case for now. It
>>>>> probably will need to be
>>>>> undo-ed after the propose change for #8015666 get integrated.
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>>>
>>>>> The proposal for #8015666 is to keep the "existing" behavior of
>>>>> ZipEntry.getTime()
>>>>> to return a LastModifiedTime converted from the zip entry's
>>>>> ms-dos-formatted date/time
>>>>> field by using the "default" timezone. A new pair
>>>>> ZipEntry.get/setLastModifiedTime()
>>>>> will be added to access the "real" UTC time stored in the zip entry,
>>>>> if presents.
>>>>>
>>>>> The API doc will be updated accordingly as well to explicitly explain
>>>>> the source of the
>>>>> date/time and the its timezone sensitive conversion.
>>>>>
>>>>> -Sherman
>>>>>
>>>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this simple patch which updates regression test
>>>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>>>>
>>>>>> Please note that this patch is intended to address the test failures,
>>>>>> and that I will be immediately opening a new bug to investigate and
>>>>>> address deeper issues, and also to properly document the API.
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~emc/8016760/
>>>>>>
>>>>>> The bug report is here:
>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8016760
>>>>>>
>>>>>> Thanks,
>>>>>> Eric
> 

From naoto.sato at oracle.com  Thu Jun 27 21:41:04 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Jun 2013 21:41:04 +0000
Subject: hg: jdk8/tl/jdk: 6609431: (rb) ResourceBundle.getString() returns
	incorrect value
Message-ID: <20130627214128.48EDD485E7@hg.openjdk.java.net>

Changeset: e34e3ddb3cd8
Author:    naoto
Date:      2013-06-27 14:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e34e3ddb3cd8

6609431: (rb) ResourceBundle.getString() returns incorrect value
Reviewed-by: okutsu, sherman

! src/share/classes/java/util/Properties.java
+ test/java/util/Properties/Bug6609431.java
+ test/java/util/Properties/Bug6609431.properties



From eric.mccorkle at oracle.com  Thu Jun 27 21:46:51 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 27 Jun 2013 21:46:51 +0000
Subject: hg: jdk8/tl/langtools: 8013357: javac accepts erroneous binary
	comparison operations
Message-ID: <20130627214656.3A210485E8@hg.openjdk.java.net>

Changeset: 5c548a8542b8
Author:    emc
Date:      2013-06-27 17:45 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c548a8542b8

8013357: javac accepts erroneous binary comparison operations
Summary: javac does not report type errors on illegal Object == primitive comparisons
Reviewed-by: abuckley, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! test/tools/javac/lambda/LambdaConv01.java
! test/tools/javac/lambda/LambdaExpr15.java
! test/tools/javac/lambda/typeInference/InferenceTest2b.java
+ test/tools/javac/types/TestComparisons.java



From joe.darcy at oracle.com  Fri Jun 28 01:43:46 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 27 Jun 2013 18:43:46 -0700
Subject: JDK 8 code review request for 8019357: Fix doclint warnings in
	java.lang.invoke
Message-ID: <51CCEA52.3040402@oracle.com>

Hi John,

Please review the changes for

     8019357: Fix doclint warnings in java.lang.invoke
     http://cr.openjdk.java.net/~darcy/8019357.0/

Thanks,

-Joe


From john.r.rose at oracle.com  Fri Jun 28 01:58:16 2013
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 27 Jun 2013 18:58:16 -0700
Subject: JDK 8 code review request for 8019357: Fix doclint warnings in
	java.lang.invoke
In-Reply-To: <51CCEA52.3040402@oracle.com>
References: <51CCEA52.3040402@oracle.com>
Message-ID: <9D18E207-E8F7-4465-B1DB-52892E0F732C@oracle.com>

On Jun 27, 2013, at 6:43 PM, Joe Darcy  wrote:

> Hi John,
> 
> Please review the changes for
> 
>    8019357: Fix doclint warnings in java.lang.invoke
>    http://cr.openjdk.java.net/~darcy/8019357.0/
> 

I read it and it is good.  Thanks for doing this.  ? John

From joe.darcy at oracle.com  Fri Jun 28 02:02:19 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 28 Jun 2013 02:02:19 +0000
Subject: hg: jdk8/tl/jdk: 8019357: Fix doclint warnings in java.lang.invoke
Message-ID: <20130628020243.A703448604@hg.openjdk.java.net>

Changeset: 29bbbb136bc5
Author:    darcy
Date:      2013-06-27 19:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29bbbb136bc5

8019357: Fix doclint warnings in java.lang.invoke
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/LambdaConversionException.java
! src/share/classes/java/lang/invoke/LambdaMetafactory.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/MethodType.java
! src/share/classes/java/lang/invoke/MutableCallSite.java
! src/share/classes/java/lang/invoke/SerializedLambda.java
! src/share/classes/java/lang/invoke/package-info.java



From xuelei.fan at oracle.com  Fri Jun 28 02:26:43 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Fri, 28 Jun 2013 02:26:43 +0000
Subject: hg: jdk8/tl/jdk: 8019359: To comment why not use no_renegotiation to
	reject client initiated renegotiation
Message-ID: <20130628022718.2C53648605@hg.openjdk.java.net>

Changeset: 60d1994f63f7
Author:    xuelei
Date:      2013-06-27 19:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d1994f63f7

8019359: To comment why not use no_renegotiation to reject client initiated renegotiation
Reviewed-by: wetmore

! src/share/classes/sun/security/ssl/ServerHandshaker.java



From paul.sandoz at oracle.com  Fri Jun 28 08:21:38 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 28 Jun 2013 08:21:38 +0000
Subject: hg: jdk8/tl/jdk: 8009736: Comparator API cleanup
Message-ID: <20130628082202.5780D48629@hg.openjdk.java.net>

Changeset: c1df54fd19b2
Author:    henryjen
Date:      2013-06-11 13:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1df54fd19b2

8009736: Comparator API cleanup
Reviewed-by: psandoz, briangoetz, mduigou, plevart

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SortedOps.java
! test/java/nio/file/Files/StreamTest.java
! test/java/util/Collection/ListDefaults.java
+ test/java/util/Comparator/BasicTest.java
+ test/java/util/Comparator/TypeTest.java
- test/java/util/Comparators/BasicTest.java
+ test/java/util/Map/EntryComparators.java
+ test/java/util/function/BinaryOperator/BasicTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test/sun/misc/JavaLangAccess/NewUnsafeString.java



From paul.sandoz at oracle.com  Fri Jun 28 08:30:55 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Fri, 28 Jun 2013 08:30:55 +0000
Subject: hg: jdk8/tl/jdk: 8012987: Optimizations for Stream.limit/substream
Message-ID: <20130628083121.C815E4862C@hg.openjdk.java.net>

Changeset: 28b71c97a72d
Author:    psandoz
Date:      2013-06-28 10:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28b71c97a72d

8012987: Optimizations for Stream.limit/substream
Reviewed-by: mduigou
Contributed-by: Brian Goetz , Paul Sandoz 

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java
! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java



From eric.mccorkle at oracle.com  Fri Jun 28 10:55:31 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Fri, 28 Jun 2013 10:55:31 +0000
Subject: hg: jdk8/tl/langtools: 8016760: Failure of regression test
	langtools/tools/javac/T6725036.java
Message-ID: <20130628105536.1F92148636@hg.openjdk.java.net>

Changeset: 6101e52ce9e3
Author:    emc
Date:      2013-06-28 06:54 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6101e52ce9e3

8016760: Failure of regression test langtools/tools/javac/T6725036.java
Summary: Marking the failing test @ignore; the proposed change for 8015666 addresses the underlying issue
Reviewed-by: jjg

! test/tools/javac/T6725036.java



From paul.sandoz at oracle.com  Fri Jun 28 12:22:11 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Jun 2013 14:22:11 +0200
Subject: RFR 8019370: Sync j.u.c Fork/Join from 166 to tl
Message-ID: 

Hi,

This webrev contains updates of java.util.concurrent Fork/Join, executors, and related classes from 166:

  http://cr.openjdk.java.net/~psandoz/tl/JDK-8019370-fork-join/webrev/

There are also various doc updates/fixes included.

Most of this code has been in the lambda repo for quite a while (the diff between 166 and lambda is much much smaller than the diff between tl and lambda). This webrev was derived from the lambda code base after first syncing lambda with associated files from 166.

Paul.

From vicente.romero at oracle.com  Fri Jun 28 12:21:49 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 28 Jun 2013 12:21:49 +0000
Subject: hg: jdk8/tl/langtools: 6473148: TreePath.iterator() should document
	the iteration order
Message-ID: <20130628122157.9B4084863A@hg.openjdk.java.net>

Changeset: bb06c412d079
Author:    vromero
Date:      2013-06-28 13:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb06c412d079

6473148: TreePath.iterator() should document the iteration order
Reviewed-by: mcimadamore

! src/share/classes/com/sun/source/util/TreePath.java



From Alan.Bateman at oracle.com  Fri Jun 28 13:02:37 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 28 Jun 2013 14:02:37 +0100
Subject: Question on HashMap change in 8011200
In-Reply-To: <51CCAAE5.4010707@univ-mlv.fr>
References: <51CBF181.1020301@linux.vnet.ibm.com>
	<51CCAAE5.4010707@univ-mlv.fr>
Message-ID: <51CD896D.9030807@oracle.com>

On 27/06/2013 22:13, Remi Forax wrote:
> On 06/27/2013 10:02 AM, Shi Jun Zhang wrote:
>> Hi,
>>
>> There are some isEmpty() check added into get/remove methods since 
>> 8011200 to return directly if HashMap is empty. However isEmpty is a 
>> non-final public method which can be overridden by subclass. If the 
>> subclass defines isEmpty differently from HashMap, it would cause 
>> problem while getting or removing elements.
>
> yes, it's a bug.
> Could you report it ?
>
> R?mi
I've created a bug to track this:

8019381: HashMap.isEmpty is non-final, potential issues for get/remove

-Alan


From vicente.romero at oracle.com  Fri Jun 28 13:36:39 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 28 Jun 2013 13:36:39 +0000
Subject: hg: jdk8/tl/langtools: 8005552:
	c.s.t.javap.AttributeWriter.visitLocalVariableTable() uses
	incorrect format string
Message-ID: <20130628133644.D79784863B@hg.openjdk.java.net>

Changeset: bdd699d7378d
Author:    vromero
Date:      2013-06-28 14:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bdd699d7378d

8005552: c.s.t.javap.AttributeWriter.visitLocalVariableTable() uses incorrect format string
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/AttributeWriter.java



From staffan.larsen at oracle.com  Fri Jun 28 14:34:38 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Fri, 28 Jun 2013 14:34:38 +0000
Subject: hg: jdk8/tl/jdk: 8019155: Update makefiles with correct jfr packages
Message-ID: <20130628143503.2043048641@hg.openjdk.java.net>

Changeset: 19a6d2d701d9
Author:    sla
Date:      2013-06-26 19:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19a6d2d701d9

8019155: Update makefiles with correct jfr packages
Reviewed-by: mgronlun, erikj

! make/common/Release.gmk
! makefiles/CreateJars.gmk



From kumar.x.srinivasan at oracle.com  Fri Jun 28 14:47:09 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 28 Jun 2013 07:47:09 -0700
Subject: RFR: 8015666: test/tools/pack200/TimeStamp.java failing
In-Reply-To: <51CC7291.1080602@oracle.com>
References: <51C34E6D.4000502@oracle.com> <51CC7099.2050007@oracle.com>
	<51CC7291.1080602@oracle.com>
Message-ID: <51CDA1ED.9040302@oracle.com>

Some nits while reading the changes:
1. ZipEntry.java
    a. typo:

+     * Sets the laste access time of the entry.


    b. extra space

+                case EXTID_ZIP64 :

2. ZipOutputStream.java
I think it would be nice to have the flags 0x1, 0x2 and 0x4 defined
as constants, this will also help a casual reader as to what this means.


Besides my previous concern with finish(), everything else appears to be ok.

Kumar


> On 06/27/2013 10:04 AM, Kumar Srinivasan wrote:
>> Hi Sherman,
>>
>> I started looking at this, my initial comment, the Unpacker.unpack
>> does not close its output and  we allow multiple pack  files to be 
>> concatenated,
>> I am assuming out.finish() will allow further jar files to be appended ?
>> or would this cause a problem ?
>
> No, out.finish() will not allow further entry appending.  Then, it 
> appears
> we need to have a different approach to "finish" the Jar/ZipOutputStream.
> What need to be done here is that either out.close/finish() need to be
> invoked under the UTC locale as well (to output the time stamps in cen
> table correctly).  This is another "incompatible" change of the previous
> change, in which the msdosTime<->javaTime conversion no longer
> occurs during the ZipEntry.set/getTime(), but during the read and write
> the ZipEntry from/to the zip file.
>
> -Sherman
>
>
>>
>> Kumar
>>
>>> Hi,
>>>
>>> The zip time related changes[1] I pushed back last month appears
>>> to have the compatibility risk of breaking existing code. The main
>>> idea in that changeset is to use the more accurate and timezone
>>> insensitive utc time stored in the extra field for the 
>>> ZipEntry.set/getTime()
>>> if possible. However it turns out the reality is that the code out 
>>> there
>>> might have already had some interesting workaround/hack solution
>>> to workaround the problem that the time stamp stored in the "standard'
>>> zip entry header is a MS-DOS standard date/time, which is a "local
>>> date/time" and sensitive to timezone, in which, if the zip is archived
>>> in time zone A (our implementation converts the "java" time to dos
>>> time by using the default tz A) and then transferred/un-archived in
>>> a different zone B (use default tz B to convert back to java time), we
>>> have a time stamp mess up. The "workaround" from pack200 for this
>>> issue when pack/unpacking a jar file is to "specify/recommend/suggest"
>>> in its spec that the "time zone" in a jar file entry is assumed to 
>>> be "UTC",
>>> so the pack/unpack200 implementation set the "default time" to utc
>>> before the pack/unpack and set it back to the original after that. 
>>> It worked
>>> "perfectly" for a roundtrip pack/unpacking, until the changeset [2], in
>>> which ZipEntry.getTime() (packing) returns a real utc time and the 
>>> following
>>> ZipEntry.setTime() (unpacking), then mess up the MS-DOS date/time
>>> entry, this is the root cause of this regression.
>>>
>>> Given the facts that
>>> (1) there are actually two real physical time stamps in a zip file 
>>> header,
>>> one is in the date/time fields, which is MS-DOS-local-date/time-with-2-
>>> seconds-granularity , one is in the extra data field, which is 
>>> UTC-1-second
>>> -granularity
>>> (2) and there are applications over there that have dependency on the
>>> MS-DOS date/time stamp.
>>>
>>> I'm proposing the following approach to add the functionality of 
>>> supporting
>>> the "utc-date/time-with-1-second granularity" and keep the old behavior
>>> of the get/setTime() of the ZipEntry.
>>>
>>> (1) keep the time/setTime()/getTime() for the MS-DOS standard 
>>> date/time.
>>>      To set via the old setTime() will only store the time into 
>>> zip's standard
>>>      date/time field, which is in MS-DOS date/time. And getTime() 
>>> only returns
>>>      the date/time from that field, when read from the zip file/stream.
>>> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>>>      and the last modified time set via the new method will also set 
>>> the "time",
>>>      and the getLastModifiedTime() also returns the "time", if the 
>>> UTC time
>>>      stamp fields are not set in the zip file header. The idea is 
>>> that for the new
>>>      application, the recommendation is to use 
>>> ZipEntry.set/getLastModifiedTime()
>>>      for better/correct time stamp, but the existing apps keep the 
>>> same behavior.
>>> (3) jar and ZipOutputStream are updated to use the 
>>> set/getLastModifiedTime().
>>> (4) Pack/unpack continues to use the set/getTime(), so the current 
>>> workaround
>>>      continues work. I will leave this to Kuma to decide how it 
>>> should be handled
>>>      going forward. (there are two facts need to be considered here, 
>>> a) the
>>>      existing jar file might not have the utc time instored, and b) 
>>> all "extra" data
>>>      are wiped out during the pack/unpacking process)
>>> (5) additionally add another pair of atime/get/setLastAccessTime and
>>>      ctime/get/setCreationTime().
>>> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the 
>>> "new"
>>>      nio FileTime, instead of the "long". This may add some 
>>> additional cost of
>>>      conversion when working with them, but may also help improve the
>>>      performance if the time stamps are directly from nio file 
>>> system when
>>>      get/set XYZTime. Good/bad?
>>>
>>> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>>>
>>> Comment, option and suggestion are appreciated.
>>>
>>> -Sherman
>>>
>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f
>>
>



From alan.bateman at oracle.com  Fri Jun 28 15:20:18 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 28 Jun 2013 15:20:18 +0000
Subject: hg: jdk8/tl/jdk: 8019380: doclint warnings in java.nio,
	java.nio.file.**, java.nio.channels.**
Message-ID: <20130628152041.C935D48647@hg.openjdk.java.net>

Changeset: 04378a645944
Author:    alanb
Date:      2013-06-28 16:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04378a645944

8019380: doclint warnings in java.nio, java.nio.file.**, java.nio.channels.**
Reviewed-by: chegar

! src/share/classes/java/nio/Buffer.java
! src/share/classes/java/nio/MappedByteBuffer.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/channels/AsynchronousByteChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannel.java
! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java
! src/share/classes/java/nio/channels/AsynchronousFileChannel.java
! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java
! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java
! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/FileChannel.java
! src/share/classes/java/nio/channels/FileLock.java
! src/share/classes/java/nio/channels/MulticastChannel.java
! src/share/classes/java/nio/channels/NetworkChannel.java
! src/share/classes/java/nio/channels/Pipe.java
! src/share/classes/java/nio/channels/SelectableChannel.java
! src/share/classes/java/nio/channels/SelectionKey.java
! src/share/classes/java/nio/channels/Selector.java
! src/share/classes/java/nio/channels/ServerSocketChannel.java
! src/share/classes/java/nio/channels/SocketChannel.java
! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java
! src/share/classes/java/nio/channels/spi/AbstractSelector.java
! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java
! src/share/classes/java/nio/channels/spi/SelectorProvider.java
! src/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/share/classes/java/nio/charset/Charset.java
! src/share/classes/java/nio/charset/CoderResult.java
! src/share/classes/java/nio/charset/spi/CharsetProvider.java
! src/share/classes/java/nio/file/FileStore.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/FileSystems.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/WatchEvent.java
! src/share/classes/java/nio/file/WatchService.java
! src/share/classes/java/nio/file/attribute/AclEntry.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/AttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java
! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileAttribute.java
! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java
! src/share/classes/java/nio/file/spi/FileSystemProvider.java
! src/share/classes/java/sql/SQLInput.java



From chris.hegarty at oracle.com  Fri Jun 28 16:01:17 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 28 Jun 2013 17:01:17 +0100
Subject: RFR 8019370: Sync j.u.c Fork/Join from 166 to tl
In-Reply-To: 
References: 
Message-ID: <51CDB34D.4000900@oracle.com>

Thanks for doing this Paul. I don't see anything objectionable, after a 
cursory look.

We can have added confidence, since the changes against lambda are much 
smaller.

-Chris.

On 06/28/2013 01:22 PM, Paul Sandoz wrote:
> Hi,
>
> This webrev contains updates of java.util.concurrent Fork/Join, executors, and related classes from 166:
>
>    http://cr.openjdk.java.net/~psandoz/tl/JDK-8019370-fork-join/webrev/
>
> There are also various doc updates/fixes included.
>
> Most of this code has been in the lambda repo for quite a while (the diff between 166 and lambda is much much smaller than the diff between tl and lambda). This webrev was derived from the lambda code base after first syncing lambda with associated files from 166.
>
> Paul.
>


From zhangshj at linux.vnet.ibm.com  Fri Jun 28 16:05:39 2013
From: zhangshj at linux.vnet.ibm.com (Shi Jun Zhang)
Date: Sat, 29 Jun 2013 00:05:39 +0800
Subject: Question on HashMap change in 8011200
In-Reply-To: <51CD896D.9030807@oracle.com>
References: <51CBF181.1020301@linux.vnet.ibm.com>
	<51CCAAE5.4010707@univ-mlv.fr> <51CD896D.9030807@oracle.com>
Message-ID: <51CDB453.5010003@linux.vnet.ibm.com>

On 6/28/2013 9:02 PM, Alan Bateman wrote:
> On 27/06/2013 22:13, Remi Forax wrote:
>> On 06/27/2013 10:02 AM, Shi Jun Zhang wrote:
>>> Hi,
>>>
>>> There are some isEmpty() check added into get/remove methods since 
>>> 8011200 to return directly if HashMap is empty. However isEmpty is a 
>>> non-final public method which can be overridden by subclass. If the 
>>> subclass defines isEmpty differently from HashMap, it would cause 
>>> problem while getting or removing elements.
>>
>> yes, it's a bug.
>> Could you report it ?
>>
>> R?mi
> I've created a bug to track this:
>
> 8019381: HashMap.isEmpty is non-final, potential issues for get/remove
>
> -Alan
>
Thanks, Alan.

I'm quite busy today and do not have time to report it until now. Thanks 
for your help.

I will provide a webrev next Monday for review.

-- 
Regards,

Shi Jun Zhang



From chris.hegarty at oracle.com  Fri Jun 28 15:45:56 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 28 Jun 2013 15:45:56 +0000
Subject: hg: jdk8/tl/jdk: 4 new changesets
Message-ID: <20130628154655.7175A48648@hg.openjdk.java.net>

Changeset: 1919c226b427
Author:    dl
Date:      2013-06-28 12:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1919c226b427

8017739: ReentrantReadWriteLock is confused by the Threads with reused IDs
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java

Changeset: 0e24065a75db
Author:    dl
Date:      2013-06-28 12:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e24065a75db

8019377: Sync j.u.c locks and atomic from 166 to tl
Reviewed-by: chegar

! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java
! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java
! src/share/classes/java/util/concurrent/atomic/package-info.java
! src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/share/classes/java/util/concurrent/locks/Condition.java
! src/share/classes/java/util/concurrent/locks/Lock.java
! src/share/classes/java/util/concurrent/locks/LockSupport.java
! src/share/classes/java/util/concurrent/locks/ReadWriteLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/share/classes/java/util/concurrent/locks/StampedLock.java

Changeset: ff0242ed08db
Author:    jzavgren
Date:      2013-06-28 16:38 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff0242ed08db

8015799: HttpURLConnection.getHeaderFields() throws IllegalArgumentException
Reviewed-by: chegar, dsamersoff, khazra

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/java/net/CookieHandler/EmptyCookieHeader.java

Changeset: 52b4527d3fc7
Author:    chegar
Date:      2013-06-28 16:39 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52b4527d3fc7

Merge




From paul.sandoz at oracle.com  Fri Jun 28 16:19:15 2013
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Jun 2013 18:19:15 +0200
Subject: RFR 8019370: Sync j.u.c Fork/Join from 166 to tl
In-Reply-To: <51CDB34D.4000900@oracle.com>
References: 
	<51CDB34D.4000900@oracle.com>
Message-ID: 

On Jun 28, 2013, at 6:01 PM, Chris Hegarty  wrote:
> Thanks for doing this Paul. I don't see anything objectionable, after a cursory look.
> 

Thanks.


> We can have added confidence, since the changes against lambda are much smaller.
> 

Plus i ran a jprt job (for this and the previous related patch) and it reported no relevant failures.

Paul.

From daniel.fuchs at oracle.com  Fri Jun 28 16:32:44 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 28 Jun 2013 18:32:44 +0200
Subject: RFR: 8017174 - NPE when using Logger.getAnonymousLogger or
	LogManager.getLogManager().getLogger
Message-ID: <51CDBAAC.1040808@oracle.com>

Hi,

Please find below a patch for jdk8 for:

8017174 - NPE when using Logger.getAnonymousLogger or 
LogManager.getLogManager().getLogger



The issue was that the lazy initialization of LoggerContext was
not working correctly - leading to applets seeing a partially
initialized tree where the root logger hadn't been added
yet - hence the NPE - as the root logger was unexpectedly null.


best regards,

-- daniel


From mandy.chung at oracle.com  Fri Jun 28 17:06:26 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Jun 2013 10:06:26 -0700
Subject: RFR: JDK-8014045 -
	test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
	failing intermittently
In-Reply-To: <51C2DE6E.3030605@oracle.com>
References: <51B9CD59.5030409@oracle.com> <51BA2601.3070609@oracle.com>
	<51C1733A.7020008@oracle.com> <51C1F788.7090707@oracle.com>
	<51C2DE6E.3030605@oracle.com>
Message-ID: <51CDC292.6020603@oracle.com>

Hi Daniel,

On 6/20/2013 3:50 AM, Daniel Fuchs wrote:
> Right. I have changed the test to temporarily retrieve the named loggers
> and keep them in an HashMap - this way they should not be gc'ed.
>
> 

This looks good.  This is a better approach and I like it so that the 
test can verify precisely the returned values from two mbeans.

Mandy


From jason.uh at oracle.com  Fri Jun 28 17:48:34 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Fri, 28 Jun 2013 17:48:34 +0000
Subject: hg: jdk8/tl/jdk: 8019360: Cleanup of the javadoc  tag in
	java.security.*
Message-ID: <20130628174901.2BD4348651@hg.openjdk.java.net>

Changeset: 389f59e6288f
Author:    juh
Date:      2013-06-28 10:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/389f59e6288f

8019360: Cleanup of the javadoc  tag in java.security.*
Summary: Convert to {@code ...} tags. convert package.html to package-info.java.
Reviewed-by: darcy

! src/share/classes/java/security/AccessControlContext.java
! src/share/classes/java/security/AccessControlException.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/security/AlgorithmParameterGenerator.java
! src/share/classes/java/security/AlgorithmParameterGeneratorSpi.java
! src/share/classes/java/security/AlgorithmParameters.java
! src/share/classes/java/security/AlgorithmParametersSpi.java
! src/share/classes/java/security/AllPermission.java
! src/share/classes/java/security/AuthProvider.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/Certificate.java
! src/share/classes/java/security/CodeSigner.java
! src/share/classes/java/security/CodeSource.java
! src/share/classes/java/security/DigestException.java
! src/share/classes/java/security/DigestInputStream.java
! src/share/classes/java/security/DigestOutputStream.java
! src/share/classes/java/security/DomainCombiner.java
! src/share/classes/java/security/GeneralSecurityException.java
! src/share/classes/java/security/Guard.java
! src/share/classes/java/security/GuardedObject.java
! src/share/classes/java/security/Identity.java
! src/share/classes/java/security/IdentityScope.java
! src/share/classes/java/security/InvalidAlgorithmParameterException.java
! src/share/classes/java/security/InvalidKeyException.java
! src/share/classes/java/security/Key.java
! src/share/classes/java/security/KeyException.java
! src/share/classes/java/security/KeyFactory.java
! src/share/classes/java/security/KeyFactorySpi.java
! src/share/classes/java/security/KeyManagementException.java
! src/share/classes/java/security/KeyPair.java
! src/share/classes/java/security/KeyPairGenerator.java
! src/share/classes/java/security/KeyPairGeneratorSpi.java
! src/share/classes/java/security/KeyRep.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/KeyStoreException.java
! src/share/classes/java/security/KeyStoreSpi.java
! src/share/classes/java/security/MessageDigest.java
! src/share/classes/java/security/MessageDigestSpi.java
! src/share/classes/java/security/NoSuchAlgorithmException.java
! src/share/classes/java/security/Permission.java
! src/share/classes/java/security/PermissionCollection.java
! src/share/classes/java/security/Permissions.java
! src/share/classes/java/security/Policy.java
! src/share/classes/java/security/PolicySpi.java
! src/share/classes/java/security/PrivilegedAction.java
! src/share/classes/java/security/PrivilegedActionException.java
! src/share/classes/java/security/PrivilegedExceptionAction.java
! src/share/classes/java/security/ProtectionDomain.java
! src/share/classes/java/security/Provider.java
! src/share/classes/java/security/ProviderException.java
! src/share/classes/java/security/PublicKey.java
! src/share/classes/java/security/SecureClassLoader.java
! src/share/classes/java/security/SecureRandom.java
! src/share/classes/java/security/SecureRandomSpi.java
! src/share/classes/java/security/Security.java
! src/share/classes/java/security/SecurityPermission.java
! src/share/classes/java/security/Signature.java
! src/share/classes/java/security/SignatureException.java
! src/share/classes/java/security/SignatureSpi.java
! src/share/classes/java/security/SignedObject.java
! src/share/classes/java/security/Signer.java
! src/share/classes/java/security/UnresolvedPermission.java
! src/share/classes/java/security/acl/Acl.java
! src/share/classes/java/security/acl/AclEntry.java
! src/share/classes/java/security/acl/Group.java
! src/share/classes/java/security/acl/Owner.java
+ src/share/classes/java/security/acl/package-info.java
- src/share/classes/java/security/acl/package.html
+ src/share/classes/java/security/cert/package-info.java
- src/share/classes/java/security/cert/package.html
! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java
! src/share/classes/java/security/interfaces/DSAParams.java
! src/share/classes/java/security/interfaces/DSAPrivateKey.java
! src/share/classes/java/security/interfaces/DSAPublicKey.java
+ src/share/classes/java/security/interfaces/package-info.java
- src/share/classes/java/security/interfaces/package.html
+ src/share/classes/java/security/package-info.java
- src/share/classes/java/security/package.html
+ src/share/classes/java/security/spec/package-info.java
- src/share/classes/java/security/spec/package.html



From joe.darcy at oracle.com  Fri Jun 28 17:54:54 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 28 Jun 2013 10:54:54 -0700
Subject: JDK 8 code review request for doclint cleanup of javax.naming.*
Message-ID: <51CDCDEE.8000103@oracle.com>

Hello,

Still more doclint fixes for review below; this time to javax.naming.*.

Thanks,

-Joe

--- a/src/share/classes/javax/naming/CompositeName.java    Fri Jun 28 
16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/CompositeName.java    Fri Jun 28 
10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -42,7 +42,7 @@
   * The most significant component is at index 0.
   * An empty composite name has no components.
   *
    
- * 
    JNDI Composite Name Syntax
    
+ * 
    JNDI Composite Name Syntax
    
   * JNDI defines a standard string representation for composite names. This
   * representation is the concatenation of the components of a 
composite name
   * from left to right using the component separator (a forward
@@ -73,12 +73,12 @@
   * a separator) denotes a trailing empty component.
   * Adjacent component separators denote an empty component.
   *
    
- *
    Composite Name Examples
    
+ *
    Composite Name Examples
    
   *This table shows examples of some composite names. Each row shows
   *the string form of a composite name and its corresponding structural 
form
   *(CompositeName).
   *
    
-
    Rounding mode UNNECESSARY Examples
    Input NumberInput rounded to one digit
     with {@code UNNECESSARY} rounding
>          *
    5.5 throw {@code ArithmeticException}
    
+
    
@@ -137,14 +137,14 @@
  
    

  
    
  String Name
    
  
    
   * 
    
- *
    Composition Examples
    
+ *
    Composition Examples
    
   * Here are some composition examples.  The right column shows composing
   * string composite names while the left column shows composing the
   * corresponding CompositeNames.  Notice that composing the
   * string forms of two composite names simply involves concatenating
   * their string forms together.

-
     
+
     
    
@@ -189,7 +189,7 @@

  
    

  
    
  String Names
    
   *
    
- *
    Multithreaded Access
    
+ *
    Multithreaded Access
    
   * A CompositeName instance is not synchronized against 
concurrent
   * multithreaded access. Multiple threads trying to access and modify a
   * CompositeName should lock the object.
diff -r 52b4527d3fc7 src/share/classes/javax/naming/CompoundName.java
--- a/src/share/classes/javax/naming/CompoundName.java    Fri Jun 28 
16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/CompoundName.java    Fri Jun 28 
10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -39,7 +39,7 @@
   * The most significant component is at index 0.
   * An empty compound name has no components.
   *
    
- * 
    Compound Name Syntax
    
+ * 
    Compound Name Syntax
    
   * The syntax of a compound name is specified using a set of properties:
   *
    
   *  
    jndi.syntax.direction
@@ -136,7 +136,7 @@
   * so that when the same string is parsed, it will yield the same 
components
   * of the original compound name.
   *
    
- *
    Multithreaded Access
    
+ *
    Multithreaded Access
    
   * A CompoundName instance is not synchronized against concurrent
   * multithreaded access. Multiple threads trying to access and modify a
   * CompoundName should lock the object.
diff -r 52b4527d3fc7 src/share/classes/javax/naming/Context.java
--- a/src/share/classes/javax/naming/Context.java    Fri Jun 28 16:39:15 
2013 +0100
+++ b/src/share/classes/javax/naming/Context.java    Fri Jun 28 10:54:12 
2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2006, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -32,7 +32,7 @@
   * consists of a set of name-to-object bindings.
   * It contains methods for examining and updating these bindings.
   * 
    
- * 
    Names
    
+ * 
    Names
    
   * Each name passed as an argument to a Context method is 
relative
   * to that context.  The empty name is used to name the context itself.
   * A name parameter may never be null.
@@ -69,12 +69,12 @@
   * names in a composite namespace, at the discretion of the service
   * provider.
   *
    
- *
    Exceptions
    
+ *
    Exceptions
    
   * All the methods in this interface can throw a 
NamingException or
   * any of its subclasses. See NamingException and their 
subclasses
   * for details on each exception.
   *
    
- *
    Concurrent Access
    
+ *
    Concurrent Access
    
   * A Context instance is not guaranteed to be synchronized against
   * concurrent access by multiple threads.  Threads that need to access
   * a single Context instance concurrently should synchronize amongst
@@ -91,7 +91,7 @@
   * being followed.
   *
   *
    
- *
    Parameters
    
+ *
    Parameters
    
   * A Name parameter passed to any method of the
   * Context interface or one of its subinterfaces
   * will not be modified by the service provider.
@@ -103,7 +103,7 @@
   * The caller may subsequently modify it; the service provider may not.
   *
   *
    
- *
    Environment Properties
    
+ *
    Environment Properties
    
   *
    
   * JNDI applications need a way to communicate various preferences
   * and properties that define the environment in which naming and
@@ -138,7 +138,7 @@
   *
   *
    
   *
- *
    Resource Files
    
+ *
    Resource Files
    
   *
    
   * To simplify the task of setting up the environment
   * required by a JNDI application,
@@ -151,11 +151,11 @@
   * and the value is a string in the format defined
   * for that property.  Here is an example of a JNDI resource file:
   *
- * 
    + * 
    {@code
   * 
java.naming.factory.object=com.sun.jndi.ldap.AttrsToCorba:com.wiz.from.Person
   * 
java.naming.factory.state=com.sun.jndi.ldap.CorbaToAttrs:com.wiz.from.Person
   * java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory
- * 
    
+ * }
    
   *
   * The JNDI class library reads the resource files and makes the property
   * values freely available.  Thus JNDI resource files should be considered
@@ -165,7 +165,7 @@
   * There are two kinds of JNDI resource files:
   * provider and application.
   *
- * 
    Provider Resource Files
    
+ * 
    Provider Resource Files
    
   *
   * Each service provider has an optional resource that lists properties
   * specific to that provider.  The name of this resource is:
@@ -200,7 +200,7 @@
   * The service provider's documentation should clearly state which
   * properties are allowed; other properties in the file will be ignored.
   *
- * 
    Application Resource Files
    
+ * 
    Application Resource Files
    
   *
   * When an application is deployed, it will generally have several
   * codebase directories and JARs in its classpath.  Similarly, when an
@@ -232,7 +232,7 @@
   * collects and uses all of these export lists when searching for factory
   * classes.
   *
- * 
    Search Algorithm for Properties
    
+ * 
    Search Algorithm for Properties
    
   *
   * When JNDI constructs an initial context, the context's environment
   * is initialized with properties defined in the environment parameter
diff -r 52b4527d3fc7 src/share/classes/javax/naming/InitialContext.java
--- a/src/share/classes/javax/naming/InitialContext.java    Fri Jun 28 
16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/InitialContext.java    Fri Jun 28 
10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -258,6 +258,7 @@
       * environment may be modified independently and it may be accessed
       * concurrently).
       *
+     * @param  the type of the returned object
       * @param name
       *          the name of the object to look up
       * @return  the object bound to name
@@ -276,11 +277,12 @@
     /**
       * A static method to retrieve the named object.
       * See {@link #doLookup(Name)} for details.
+     * @param  the type of the returned object
       * @param name
       *          the name of the object to look up
       * @return  the object bound to name
       * @throws  NamingException if a naming exception is encountered
-      * @since 1.6
+     * @since 1.6
       */
      @SuppressWarnings("unchecked")
      public static  T doLookup(String name)
diff -r 52b4527d3fc7 src/share/classes/javax/naming/RefAddr.java
--- a/src/share/classes/javax/naming/RefAddr.java    Fri Jun 28 16:39:15 
2013 +0100
+++ b/src/share/classes/javax/naming/RefAddr.java    Fri Jun 28 10:54:12 
2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -91,7 +91,8 @@
        * Determines whether obj is equal to this RefAddr.
        *
    
        * obj is equal to this RefAddr all of these conditions are true
-      *
       non-null
+      *
        
+      *
      •  non-null
        *
      •  instance of RefAddr
        *
      •  obj has the same address type as this RefAddr (using 
String.compareTo())
        *
      •  both obj and this RefAddr's contents are null or they are 
equal
diff -r 52b4527d3fc7 src/share/classes/javax/naming/ReferralException.java
--- a/src/share/classes/javax/naming/ReferralException.java    Fri Jun 
28 16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/ReferralException.java    Fri Jun 
28 10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -38,7 +38,7 @@
   * constructors and/or corresponding "set" methods).
   * 
        
   * The following code sample shows how ReferralException can 
be used.
- * 
        + * 
        {@code
   *      while (true) {
   *          try {
   *              bindings = ctx.listBindings(name);
@@ -51,7 +51,7 @@
   *              ctx = e.getReferralContext();
   *          }
   *      }
- * 
        
+ * }
    • 
   *
    
   * ReferralException is an abstract class. Concrete 
implementations
   * determine its synchronization and serialization properties.
diff -r 52b4527d3fc7 
src/share/classes/javax/naming/directory/DirContext.java
--- a/src/share/classes/javax/naming/directory/DirContext.java Fri Jun 
28 16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/directory/DirContext.java Fri Jun 
28 10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2005, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -32,7 +32,7 @@
   * methods for examining and updating attributes
   * associated with objects, and for searching the directory.
   * 
    
- * 
    Names
    
+ * 
    Names
    
   * Each name passed as an argument to a DirContext method is 
relative
   * to that context.  The empty name is used to name the context itself.
   * The name parameter may never be null.
@@ -51,7 +51,7 @@
   * name argument to the Context methods. These same rules
   * apply to the name argument to the DirContext methods.
   * 
    
- * 
    Attribute Models
    
+ * 
    Attribute Models
    
   * There are two basic models of what attributes should be
   * associated with.  First, attributes may be directly associated with a
   * DirContext object.
@@ -81,7 +81,7 @@
   * whether an object's attributes are stored as part of the object, or 
stored
   * within the parent object and associated with the object's name.
   * 
    
- * 
    Attribute Type Names
    
+ * 
    Attribute Type Names
    
   * In the getAttributes() and search() methods,
   * you can supply the attributes to return by supplying a list of
   * attribute names (strings).
@@ -113,7 +113,7 @@
   * 
   *
   * 
    
- *
    Operational Attributes
    
+ *
    Operational Attributes
    
   *
    
   * Some directories have the notion of "operational attributes" which are
   * attributes associated with a directory object for administrative
@@ -127,7 +127,7 @@
   * In order to retrieve operational attributes, you must name them 
explicitly.
   *
   * 
    
- * 
    Named Context
    
+ * 
    Named Context
    
   * 
    
   * There are certain methods in which the name must resolve to a context
   * (for example, when searching a single level context). The documentation
@@ -138,7 +138,7 @@
   * Aside from these methods, there is no requirement that the
   * named object be a DirContext.
   *
    
- *
    Parameters
    
+ *
    Parameters
    
   *
    
   * An Attributes, SearchControls, or array object
   * passed as a parameter to any method will not be modified by the
@@ -150,7 +150,7 @@
   * the caller.  The caller may subsequently modify it; the service
   * provider will not.
   *
    
- *
    Exceptions
    
+ *
    Exceptions
    
   *
    
   * All the methods in this interface can throw a NamingException or
   * any of its subclasses. See NamingException and their subclasses
diff -r 52b4527d3fc7 src/share/classes/javax/naming/event/EventContext.java
--- a/src/share/classes/javax/naming/event/EventContext.java    Fri Jun 
28 16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/event/EventContext.java    Fri Jun 
28 10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -34,7 +34,7 @@
   * Contains methods for registering/deregistering listeners to be 
notified of
   * events fired when objects named in a context changes.
   *
    
- *
    Target
    
+ *
    Target
    
   * The name parameter in the addNamingListener() methods is 
referred
   * to as the target. The target, along with the scope, identify
   * the object(s) that the listener is interested in.
@@ -59,7 +59,7 @@
   * whether a EventContext supports registration
   * of nonexistent targets.
   *
    
- *
    Event Source
    
+ *
    Event Source
    
   * The EventContext instance on which you invoke the
   * registration methods is the event source of the events 
that are
   * (potentially) generated.
@@ -93,7 +93,7 @@
   * it needs to keep a reference to the listener in order to remove it
   * later). It cannot expect to do a lookup() and get another 
instance of
   * a EventContext on which to perform the deregistration.
- *
    Lifetime of Registration
    
+ *
    Lifetime of Registration
    
   * A registered listener becomes deregistered when:
   *
      
   *
    • It is removed using removeNamingListener().
@@ -105,7 +105,7 @@
   * Until that point, a EventContext instance that has outstanding
   * listeners will continue to exist and be maintained by the service 
provider.
   *
- *
      Listener Implementations
      
+ *
      Listener Implementations
      
   * The registration/deregistration methods accept an instance of
   * NamingListener. There are subinterfaces of 
NamingListener
   * for different of event types of NamingEvent.
@@ -118,7 +118,7 @@
   * of the listeners, this allows some service providers to optimize the
   * registration.
   *
- *
      Threading Issues
      
+ *
      Threading Issues
      
   *
   * Like Context instances in general, instances of
   * EventContext are not guaranteed to be thread-safe.
diff -r 52b4527d3fc7 src/share/classes/javax/naming/ldap/ControlFactory.java
--- a/src/share/classes/javax/naming/ldap/ControlFactory.java    Fri Jun 
28 16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/ldap/ControlFactory.java    Fri Jun 
28 10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -51,7 +51,7 @@
    */

  public abstract class ControlFactory {
-    /*
+    /**
       * Creates a new instance of a control factory.
       */
      protected ControlFactory() {
diff -r 52b4527d3fc7 
src/share/classes/javax/naming/ldap/InitialLdapContext.java
--- a/src/share/classes/javax/naming/ldap/InitialLdapContext.java Fri 
Jun 28 16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/ldap/InitialLdapContext.java Fri 
Jun 28 10:54:12 2013 -0700
@@ -38,7 +38,7 @@
    * javax.naming.InitialDirContext for details on 
synchronization,
    * and the policy for how an initial context is created.
    *
-  * 
      Request Controls
      
+  * 
      Request Controls
      
    * When you create an initial context (InitialLdapContext),
    * you can specify a list of request controls.
    * These controls will be used as the request controls for any
diff -r 52b4527d3fc7 src/share/classes/javax/naming/ldap/LdapContext.java
--- a/src/share/classes/javax/naming/ldap/LdapContext.java    Fri Jun 28 
16:39:15 2013 +0100
+++ b/src/share/classes/javax/naming/ldap/LdapContext.java    Fri Jun 28 
10:54:12 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -78,10 +78,8 @@
   * 
      Context Request Controls
      
   * There are two ways in which a context instance gets its request 
controls:
   * 
        
- * 
- * 
      1. ldapContext.newInstance(reqCtls)
- * 
      2. ldapContext.setRequestControls(reqCtls)
- * 
+ * 
      3. ldapContext.newInstance(reqCtls)
+ * 
      4. ldapContext.setRequestControls(reqCtls)
   * 
      
   * where ldapContext is an instance of LdapContext.
   * Specifying null or an empty array for reqCtls
@@ -102,12 +100,10 @@
   * 
      Connection Request Controls
      
   * There are three ways in which connection request controls are set:
   * 
        
- * 
- * 
      1. 
- * new InitialLdapContext(env, connCtls)
- * 
      2. refException.getReferralContext(env, connCtls)
- * 
      3. ldapContext.reconnect(connCtls);
- * 
+ * 
      4. 
+ * new InitialLdapContext(env, connCtls)
+ * 
      5. refException.getReferralContext(env, 
connCtls)
+ * 
      6. ldapContext.reconnect(connCtls);
   * 
      
   * where refException is an instance of
   * LdapReferralException, and ldapContext is an



From Lance.Andersen at oracle.com  Fri Jun 28 18:13:36 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 28 Jun 2013 14:13:36 -0400
Subject: JDK 8 code review request for doclint cleanup of javax.naming.*
In-Reply-To: <51CDCDEE.8000103@oracle.com>
References: <51CDCDEE.8000103@oracle.com>
Message-ID: 

Hi Joe,

Looks good.

fwiw,  I was able to use H3 vs H1 tags to make doclint accessibility happy.    Not sure if it matters below but thought I would point it out if you want a smaller heading

Best
Lance
On Jun 28, 2013, at 1:54 PM, Joe Darcy wrote:

> Hello,
> 
> Still more doclint fixes for review below; this time to javax.naming.*.
> 
> Thanks,
> 
> -Joe
> 
> --- a/src/share/classes/javax/naming/CompositeName.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/CompositeName.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -42,7 +42,7 @@
>  * The most significant component is at index 0.
>  * An empty composite name has no components.
>  *
      
> - * 
      JNDI Composite Name Syntax
      
> + * 
      JNDI Composite Name Syntax
      
>  * JNDI defines a standard string representation for composite names. This
>  * representation is the concatenation of the components of a composite name
>  * from left to right using the component separator (a forward
> @@ -73,12 +73,12 @@
>  * a separator) denotes a trailing empty component.
>  * Adjacent component separators denote an empty component.
>  *
      
> - *
      Composite Name Examples
      
> + *
      Composite Name Examples
      
>  *This table shows examples of some composite names. Each row shows
>  *the string form of a composite name and its corresponding structural form
>  *(CompositeName).
>  *
      
> -
> +
      
> 
> 
> 
> @@ -137,14 +137,14 @@
> 
> 
      String Name
      
>  * 
      
> - *
      Composition Examples
      
> + *
      Composition Examples
      
>  * Here are some composition examples.  The right column shows composing
>  * string composite names while the left column shows composing the
>  * corresponding CompositeNames.  Notice that composing the
>  * string forms of two composite names simply involves concatenating
>  * their string forms together.
> 
> -
       
> +
       
      
> 
> 
> 
> @@ -189,7 +189,7 @@
> 
> 
      String Names
      
>  *
      
> - *
      Multithreaded Access
      
> + *
      Multithreaded Access
      
>  * A CompositeName instance is not synchronized against concurrent
>  * multithreaded access. Multiple threads trying to access and modify a
>  * CompositeName should lock the object.
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/CompoundName.java
> --- a/src/share/classes/javax/naming/CompoundName.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/CompoundName.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
>  * The most significant component is at index 0.
>  * An empty compound name has no components.
>  *
      
> - * 
      Compound Name Syntax
      
> + * 
      Compound Name Syntax
      
>  * The syntax of a compound name is specified using a set of properties:
>  *
      
>  *  
      jndi.syntax.direction
> @@ -136,7 +136,7 @@
>  * so that when the same string is parsed, it will yield the same components
>  * of the original compound name.
>  *
      
> - *
      Multithreaded Access
      
> + *
      Multithreaded Access
      
>  * A CompoundName instance is not synchronized against concurrent
>  * multithreaded access. Multiple threads trying to access and modify a
>  * CompoundName should lock the object.
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/Context.java
> --- a/src/share/classes/javax/naming/Context.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/Context.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2006, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -32,7 +32,7 @@
>  * consists of a set of name-to-object bindings.
>  * It contains methods for examining and updating these bindings.
>  * 
      
> - * 
      Names
      
> + * 
      Names
      
>  * Each name passed as an argument to a Context method is relative
>  * to that context.  The empty name is used to name the context itself.
>  * A name parameter may never be null.
> @@ -69,12 +69,12 @@
>  * names in a composite namespace, at the discretion of the service
>  * provider.
>  *
      
> - *
      Exceptions
      
> + *
      Exceptions
      
>  * All the methods in this interface can throw a NamingException or
>  * any of its subclasses. See NamingException and their subclasses
>  * for details on each exception.
>  *
      
> - *
      Concurrent Access
      
> + *
      Concurrent Access
      
>  * A Context instance is not guaranteed to be synchronized against
>  * concurrent access by multiple threads.  Threads that need to access
>  * a single Context instance concurrently should synchronize amongst
> @@ -91,7 +91,7 @@
>  * being followed.
>  *
>  *
      
> - *
      Parameters
      
> + *
      Parameters
      
>  * A Name parameter passed to any method of the
>  * Context interface or one of its subinterfaces
>  * will not be modified by the service provider.
> @@ -103,7 +103,7 @@
>  * The caller may subsequently modify it; the service provider may not.
>  *
>  *
      
> - *
      Environment Properties
      
> + *
      Environment Properties
      
>  *
      
>  * JNDI applications need a way to communicate various preferences
>  * and properties that define the environment in which naming and
> @@ -138,7 +138,7 @@
>  *
>  *
      
>  *
> - *
      Resource Files
      
> + *
      Resource Files
      
>  *
      
>  * To simplify the task of setting up the environment
>  * required by a JNDI application,
> @@ -151,11 +151,11 @@
>  * and the value is a string in the format defined
>  * for that property.  Here is an example of a JNDI resource file:
>  *
> - * 
      > + * 
      {@code
>  * java.naming.factory.object=com.sun.jndi.ldap.AttrsToCorba:com.wiz.from.Person
>  * java.naming.factory.state=com.sun.jndi.ldap.CorbaToAttrs:com.wiz.from.Person
>  * java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory
> - * 
      
> + * }
>  *
>  * The JNDI class library reads the resource files and makes the property
>  * values freely available.  Thus JNDI resource files should be considered
> @@ -165,7 +165,7 @@
>  * There are two kinds of JNDI resource files:
>  * provider and application.
>  *
> - * 
      Provider Resource Files
      
> + * 
      Provider Resource Files
      
>  *
>  * Each service provider has an optional resource that lists properties
>  * specific to that provider.  The name of this resource is:
> @@ -200,7 +200,7 @@
>  * The service provider's documentation should clearly state which
>  * properties are allowed; other properties in the file will be ignored.
>  *
> - * 
      Application Resource Files
      
> + * 
      Application Resource Files
      
>  *
>  * When an application is deployed, it will generally have several
>  * codebase directories and JARs in its classpath.  Similarly, when an
> @@ -232,7 +232,7 @@
>  * collects and uses all of these export lists when searching for factory
>  * classes.
>  *
> - * 
      Search Algorithm for Properties
      
> + * 
      Search Algorithm for Properties
      
>  *
>  * When JNDI constructs an initial context, the context's environment
>  * is initialized with properties defined in the environment parameter
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/InitialContext.java
> --- a/src/share/classes/javax/naming/InitialContext.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/InitialContext.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -258,6 +258,7 @@
>      * environment may be modified independently and it may be accessed
>      * concurrently).
>      *
> +     * @param  the type of the returned object
>      * @param name
>      *          the name of the object to look up
>      * @return  the object bound to name
> @@ -276,11 +277,12 @@
>    /**
>      * A static method to retrieve the named object.
>      * See {@link #doLookup(Name)} for details.
> +     * @param  the type of the returned object
>      * @param name
>      *          the name of the object to look up
>      * @return  the object bound to name
>      * @throws  NamingException if a naming exception is encountered
> -      * @since 1.6
> +     * @since 1.6
>      */
>     @SuppressWarnings("unchecked")
>     public static  T doLookup(String name)
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/RefAddr.java
> --- a/src/share/classes/javax/naming/RefAddr.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/RefAddr.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -91,7 +91,8 @@
>       * Determines whether obj is equal to this RefAddr.
>       *
      
>       * obj is equal to this RefAddr all of these conditions are true
> -      *
         non-null
> +      *
          
> +      *
        •  non-null
>       *
        •  instance of RefAddr
>       *
        •  obj has the same address type as this RefAddr (using String.compareTo())
>       *
        •  both obj and this RefAddr's contents are null or they are equal
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/ReferralException.java
> --- a/src/share/classes/javax/naming/ReferralException.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/ReferralException.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -38,7 +38,7 @@
>  * constructors and/or corresponding "set" methods).
>  * 
          
>  * The following code sample shows how ReferralException can be used.
> - * 
          > + * 
          {@code
>  *      while (true) {
>  *          try {
>  *              bindings = ctx.listBindings(name);
> @@ -51,7 +51,7 @@
>  *              ctx = e.getReferralContext();
>  *          }
>  *      }
> - * 
          
> + * }
>  *
          
>  * ReferralException is an abstract class. Concrete implementations
>  * determine its synchronization and serialization properties.
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/directory/DirContext.java
> --- a/src/share/classes/javax/naming/directory/DirContext.java Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/directory/DirContext.java Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2005, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -32,7 +32,7 @@
>  * methods for examining and updating attributes
>  * associated with objects, and for searching the directory.
>  * 
          
> - * 
          Names
          
> + * 
          Names
          
>  * Each name passed as an argument to a DirContext method is relative
>  * to that context.  The empty name is used to name the context itself.
>  * The name parameter may never be null.
> @@ -51,7 +51,7 @@
>  * name argument to the Context methods. These same rules
>  * apply to the name argument to the DirContext methods.
>  * 
          
> - * 
          Attribute Models
          
> + * 
          Attribute Models
          
>  * There are two basic models of what attributes should be
>  * associated with.  First, attributes may be directly associated with a
>  * DirContext object.
> @@ -81,7 +81,7 @@
>  * whether an object's attributes are stored as part of the object, or stored
>  * within the parent object and associated with the object's name.
>  * 
          
> - * 
          Attribute Type Names
          
> + * 
          Attribute Type Names
          
>  * In the getAttributes() and search() methods,
>  * you can supply the attributes to return by supplying a list of
>  * attribute names (strings).
> @@ -113,7 +113,7 @@
>  * 
        
>  *
>  * 
        
> - *
        Operational Attributes
        
> + *
        Operational Attributes
        
>  *
        
>  * Some directories have the notion of "operational attributes" which are
>  * attributes associated with a directory object for administrative
> @@ -127,7 +127,7 @@
>  * In order to retrieve operational attributes, you must name them explicitly.
>  *
>  * 
        
> - * 
        Named Context
        
> + * 
        Named Context
        
>  * 
        
>  * There are certain methods in which the name must resolve to a context
>  * (for example, when searching a single level context). The documentation
> @@ -138,7 +138,7 @@
>  * Aside from these methods, there is no requirement that the
>  * named object be a DirContext.
>  *
        
> - *
        Parameters
        
> + *
        Parameters
        
>  *
        
>  * An Attributes, SearchControls, or array object
>  * passed as a parameter to any method will not be modified by the
> @@ -150,7 +150,7 @@
>  * the caller.  The caller may subsequently modify it; the service
>  * provider will not.
>  *
        
> - *
        Exceptions
        
> + *
        Exceptions
        
>  *
        
>  * All the methods in this interface can throw a NamingException or
>  * any of its subclasses. See NamingException and their subclasses
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/event/EventContext.java
> --- a/src/share/classes/javax/naming/event/EventContext.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/event/EventContext.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2004, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -34,7 +34,7 @@
>  * Contains methods for registering/deregistering listeners to be notified of
>  * events fired when objects named in a context changes.
>  *
        
> - *
        Target
        
> + *
        Target
        
>  * The name parameter in the addNamingListener() methods is referred
>  * to as the target. The target, along with the scope, identify
>  * the object(s) that the listener is interested in.
> @@ -59,7 +59,7 @@
>  * whether a EventContext supports registration
>  * of nonexistent targets.
>  *
        
> - *
        Event Source
        
> + *
        Event Source
        
>  * The EventContext instance on which you invoke the
>  * registration methods is the event source of the events that are
>  * (potentially) generated.
> @@ -93,7 +93,7 @@
>  * it needs to keep a reference to the listener in order to remove it
>  * later). It cannot expect to do a lookup() and get another instance of
>  * a EventContext on which to perform the deregistration.
> - *
        Lifetime of Registration
        
> + *
        Lifetime of Registration
        
>  * A registered listener becomes deregistered when:
>  *
          
>  *
        • It is removed using removeNamingListener().
> @@ -105,7 +105,7 @@
>  * Until that point, a EventContext instance that has outstanding
>  * listeners will continue to exist and be maintained by the service provider.
>  *
> - *
          Listener Implementations
          
> + *
          Listener Implementations
          
>  * The registration/deregistration methods accept an instance of
>  * NamingListener. There are subinterfaces of NamingListener
>  * for different of event types of NamingEvent.
> @@ -118,7 +118,7 @@
>  * of the listeners, this allows some service providers to optimize the
>  * registration.
>  *
> - *
          Threading Issues
          
> + *
          Threading Issues
          
>  *
>  * Like Context instances in general, instances of
>  * EventContext are not guaranteed to be thread-safe.
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/ldap/ControlFactory.java
> --- a/src/share/classes/javax/naming/ldap/ControlFactory.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/ldap/ControlFactory.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -51,7 +51,7 @@
>   */
> 
> public abstract class ControlFactory {
> -    /*
> +    /**
>      * Creates a new instance of a control factory.
>      */
>     protected ControlFactory() {
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/ldap/InitialLdapContext.java
> --- a/src/share/classes/javax/naming/ldap/InitialLdapContext.java Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/ldap/InitialLdapContext.java Fri Jun 28 10:54:12 2013 -0700
> @@ -38,7 +38,7 @@
>   * javax.naming.InitialDirContext for details on synchronization,
>   * and the policy for how an initial context is created.
>   *
> -  * 
          Request Controls
          
> +  * 
          Request Controls
          
>   * When you create an initial context (InitialLdapContext),
>   * you can specify a list of request controls.
>   * These controls will be used as the request controls for any
> diff -r 52b4527d3fc7 src/share/classes/javax/naming/ldap/LdapContext.java
> --- a/src/share/classes/javax/naming/ldap/LdapContext.java    Fri Jun 28 16:39:15 2013 +0100
> +++ b/src/share/classes/javax/naming/ldap/LdapContext.java    Fri Jun 28 10:54:12 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2000, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -78,10 +78,8 @@
>  * 
          Context Request Controls
          
>  * There are two ways in which a context instance gets its request controls:
>  * 
            
> - * 
> - * 
          1. ldapContext.newInstance(reqCtls)
> - * 
          2. ldapContext.setRequestControls(reqCtls)
> - * 
> + * 
          3. ldapContext.newInstance(reqCtls)
> + * 
          4. ldapContext.setRequestControls(reqCtls)
>  * 
          
>  * where ldapContext is an instance of LdapContext.
>  * Specifying null or an empty array for reqCtls
> @@ -102,12 +100,10 @@
>  * 
          Connection Request Controls
          
>  * There are three ways in which connection request controls are set:
>  * 
            
> - * 
> - * 
          1. 
> - * new InitialLdapContext(env, connCtls)
> - * 
          2. refException.getReferralContext(env, connCtls)
> - * 
          3. ldapContext.reconnect(connCtls);
> - * 
> + * 
          4. 
> + * new InitialLdapContext(env, connCtls)
> + * 
          5. refException.getReferralContext(env, connCtls)
> + * 
          6. ldapContext.reconnect(connCtls);
>  * 
          
>  * where refException is an instance of
>  * LdapReferralException, and ldapContext is an
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From brian.burkhalter at oracle.com  Fri Jun 28 18:24:53 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 28 Jun 2013 11:24:53 -0700
Subject: Refresh - Java 8 RFR 8017540: Improve multi-threaded contention
	behavior of BigInteger.toString() radix conversion cache
Message-ID: 

This Request for Review is a refresh of this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018337.html

pertaining to this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017540

The webrev has been updated in the same location

http://cr.openjdk.java.net/~bpb/8017540/

Basic JTREG sanity testing has been performed.

Thanks,

Brian


From joe.darcy at oracle.com  Fri Jun 28 18:35:16 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 28 Jun 2013 11:35:16 -0700
Subject: JDK 8 code review request for doclint cleanup of javax.naming.*
In-Reply-To: 
References: <51CDCDEE.8000103@oracle.com>
	
Message-ID: <51CDD764.9000508@oracle.com>

Hi Lance,

Thanks for review; I'll leave the 
           tags in for now.

Cheers,

-Joe

On 06/28/2013 11:13 AM, Lance Andersen - Oracle wrote:
> Hi Joe,
>
> Looks good.
>
> fwiw,  I was able to use H3 vs H1 tags to make doclint accessibility happy.    Not sure if it matters below but thought I would point it out if you want a smaller heading
>
> Best
> Lance
> On Jun 28, 2013, at 1:54 PM, Joe Darcy wrote:
>
>> Hello,
>>
>> Still more doclint fixes for review below; this time to javax.naming.*.
>>
>> Thanks,
>>
>> -Joe
>>


From alan.bateman at oracle.com  Fri Jun 28 18:47:24 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 28 Jun 2013 18:47:24 +0000
Subject: hg: jdk8/tl/jdk: 8019384: jps and jcmd tests fail when there is a
	process started with a .war file
Message-ID: <20130628184751.D4B3748659@hg.openjdk.java.net>

Changeset: 389b8739a74e
Author:    alanb
Date:      2013-06-28 19:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/389b8739a74e

8019384: jps and jcmd tests fail when there is a process started with a .war file
Reviewed-by: dcubed, sla, mchung

! test/sun/tools/jcmd/jcmd_Output1.awk
! test/sun/tools/jps/jps-l_Output1.awk
! test/sun/tools/jps/jps_Output1.awk



From brian.burkhalter at oracle.com  Fri Jun 28 19:10:59 2013
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 28 Jun 2013 12:10:59 -0700
Subject: Java 8 RFR: 6178739 - Formatter - Zero padding flag with zero width
Message-ID: <227132A3-5CC5-4D8C-A57A-20A3E36A21C4@oracle.com>

Continuing this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018326.html

with respect to this issue

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178739

this Request for Review proposes the following change to the Formatter javadoc specification:

diff -r 8d577b3a6ca4 src/share/classes/java/util/Formatter.java
--- a/src/share/classes/java/util/Formatter.java	Fri Jun 28 11:09:10 2013 -0700
+++ b/src/share/classes/java/util/Formatter.java	Fri Jun 28 11:58:45 2013 -0700
@@ -190,7 +190,7 @@
  * 
           The optional flags is a set of characters that modify the output
  * format.  The set of valid flags depends on the conversion.
  *
- * 
           The optional width is a non-negative decimal integer indicating
+ * 
           The optional width is a positive decimal integer indicating
  * the minimum number of characters to be written to the output.
  *
  * 
           The optional precision is a non-negative decimal integer usually

The change is to require the field width to be positive rather than non-negative. Allowing a zero minimum field width seems meaningless. This matches the current behavior as defined by the format specifier regular expression:

    private static final String formatSpecifier
        = "%(\\d+\\$)?([-#+ 0,(\\<]*)?(\\d+)?(\\.\\d+)?([tT])?([a-zA-Z%])";

A CCC request for the above would naturally need to be approved if this is change were deemed acceptable.

An alternative, as previously stated, would be to handle cases like %0.4f specially but this seems to violate the letter of the specification as currently written. It would however match the behavior of C and not require a CCC request, FWIW.

Thanks,

Brian

From mandy.chung at oracle.com  Fri Jun 28 19:37:39 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Jun 2013 12:37:39 -0700
Subject: RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info()
	doesn't log without configuration
In-Reply-To: <51C1CEE9.9010200@oracle.com>
References: <51C1CEE9.9010200@oracle.com>
Message-ID: <51CDE603.1030309@oracle.com>

Hi Daniel,

On 6/19/2013 8:31 AM, Daniel Fuchs wrote:
> The fix proposed is simple. In getGlobal() we check whether
> the 'manager' variable is null - and if it is, we initialize it
> by calling LogManager.getLogManager().
> This is a pattern which is already present at other places in
> the Logger.java class file.
>

This fix is much better.  I am happy that you found this simple approach 
to avoid calling Logger.getLogger from Logger.getGlobal() as the 
LogManager class initialization is fragile and its circular dependency 
with Logger class caused several deadlock issues in the past.

I reviewed the new webrev.01.
> 

Looks good in general.  Some comments:

Logger.global is deprecated.  In LogManager static initializer, we 
should have @SuppressWarnings("deprecation") on Logger.global (probably 
need to define a local variable) to suppress the warning and together 
with your comment it will make it clear that accessing this deprecated 
field is intentional.

As you pointed out, the same pattern is used in the checkPermission() 
method.  Might be worth having a private getManager() method to replace 
direct access to the manager field in the Logger class - just a thought 
to prevent similar bug from happening again.

>
> However - initialization of LogManager has proved to be fragile
> in the past - in particular wrt deadlocks between Logger and
> LogManager caused by circular class initialization.
>

Yes indeed and it's hard to diagnose if something goes wrong.  In the 
readPrimordialConfiguration() method, it silently ignores any exception:

       } catch (Exception ex) {
            // System.err.println("Can't read logging configuration:");
            // ex.printStackTrace();
       }

I have a patch at one point that turns this into an assert so that we 
will diagnose any logging initialization issue easier.  You may want to 
consider adding this in the future.

Great to see the regression tests covering various configurations that 
looks fine. Some suggestions.

I think TestGetGlobal and TestGetGlobal2 are almost the same except 
verifyingLogger.getGlobal()vs
Logger.getLogger(Logger.GLOBAL_LOGGER_NAME)- btw they have the same 
@summary.

Have you considered merging them into one single file and having the 
argument to control which method the test will call?  That will avoid 
the duplicated code.  The downside the number of @run will be double. 
One idea is to move the @run -Djava.util.logging.manager to the 
corresponding LogManager subclass (i.e. TestLogManagerImpl.java will be 
a jtreg test that runs the tests that set itself as the global 
LogManager) that might make it easier to understand what each LogManager 
subclass is about.

You're improving the test coverage for logging which is great. It may be 
good to adopt the current convention e.g. put these tests under 
jdk/test/java/util/logging/Logger/getGlobal directory as they are for 
Logger.getGlobal method.

TestHandles and TestLogManagerImpl are in testgetglobal package and I 
suggest to move them to "testgetglobal" subdirectory.

Thanks
Mandy


From martinrb at google.com  Fri Jun 28 20:48:27 2013
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 28 Jun 2013 13:48:27 -0700
Subject: RFR 8019370: Sync j.u.c Fork/Join from 166 to tl
In-Reply-To: 
References: 
Message-ID: 

Thanks for doing this - it Looks Good To Me.

Note that this code gets tested in Doug's CVS directly, and indirectly by
various other projects (e.g. Scala) that adopt it.



On Fri, Jun 28, 2013 at 5:22 AM, Paul Sandoz  wrote:

> Hi,
>
> This webrev contains updates of java.util.concurrent Fork/Join, executors,
> and related classes from 166:
>
>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8019370-fork-join/webrev/
>
> There are also various doc updates/fixes included.
>
> Most of this code has been in the lambda repo for quite a while (the diff
> between 166 and lambda is much much smaller than the diff between tl and
> lambda). This webrev was derived from the lambda code base after first
> syncing lambda with associated files from 166.
>
> Paul.


From joe.darcy at oracle.com  Fri Jun 28 18:35:49 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 28 Jun 2013 18:35:49 +0000
Subject: hg: jdk8/tl/jdk: 8019407: Fix doclint issues in javax.naming.*
Message-ID: <20130628183613.EF80348657@hg.openjdk.java.net>

Changeset: 9d175c6cb527
Author:    darcy
Date:      2013-06-28 11:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d175c6cb527

8019407: Fix doclint issues in javax.naming.*
Reviewed-by: lancea

! src/share/classes/javax/naming/CompositeName.java
! src/share/classes/javax/naming/CompoundName.java
! src/share/classes/javax/naming/Context.java
! src/share/classes/javax/naming/InitialContext.java
! src/share/classes/javax/naming/RefAddr.java
! src/share/classes/javax/naming/ReferralException.java
! src/share/classes/javax/naming/directory/DirContext.java
! src/share/classes/javax/naming/event/EventContext.java
! src/share/classes/javax/naming/ldap/ControlFactory.java
! src/share/classes/javax/naming/ldap/InitialLdapContext.java
! src/share/classes/javax/naming/ldap/LdapContext.java



From lance.andersen at oracle.com  Fri Jun 28 22:21:09 2013
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Fri, 28 Jun 2013 18:21:09 -0400
Subject: Review needed for ResultSet.next typo bug 8019286
Message-ID: 

Hi,

Looking for a reviewer for this minor typo in ResultSet.next()

$ hg diff
diff -r 4e69a7dfbeac src/share/classes/java/sql/ResultSet.java
--- a/src/share/classes/java/sql/ResultSet.java	Thu Jun 27 10:21:22 2013 +0100
+++ b/src/share/classes/java/sql/ResultSet.java	Fri Jun 28 18:09:36 2013 -0400
@@ -148,7 +148,7 @@
 public interface ResultSet extends Wrapper, AutoCloseable {
 
     /**
-     * Moves the cursor froward one row from its current position.
+     * Moves the cursor forward one row from its current position.
      * A ResultSet cursor is initially positioned
      * before the first row; the first call to the method
      * next makes the first row the current row; the
dhcp-amer-vpn-adc-anyconnect-10-154-144-63:sql lanceandersen$ 


Best
Lance

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From mandy.chung at oracle.com  Fri Jun 28 22:43:03 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Jun 2013 15:43:03 -0700
Subject: RFR: 8017174 - NPE when using Logger.getAnonymousLogger or
	LogManager.getLogManager().getLogger
In-Reply-To: <51CDBAAC.1040808@oracle.com>
References: <51CDBAAC.1040808@oracle.com>
Message-ID: <51CE1177.8010409@oracle.com>

On 6/28/2013 9:32 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for jdk8 for:
>
> 8017174 - NPE when using Logger.getAnonymousLogger or 
> LogManager.getLogManager().getLogger
>
> 
>
> The issue was that the lazy initialization of LoggerContext was
> not working correctly - leading to applets seeing a partially
> initialized tree where the root logger hadn't been added
> yet - hence the NPE - as the root logger was unexpectedly null.
>

This change looks reasonable and another good test (thanks).   This fix 
is good to backport to 7u-dev after it's in jdk8

thanks
Mandy


From mandy.chung at oracle.com  Fri Jun 28 23:04:51 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Jun 2013 16:04:51 -0700
Subject: Review needed for ResultSet.next typo bug 8019286
In-Reply-To: 
References: 
Message-ID: <51CE1693.8060004@oracle.com>

Thumbs up.   s/froward/forward :)
Mandy

On 6/28/2013 3:21 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> Looking for a reviewer for this minor typo in ResultSet.next()
>
> $ hg diff
> diff -r 4e69a7dfbeac src/share/classes/java/sql/ResultSet.java
> --- a/src/share/classes/java/sql/ResultSet.java	Thu Jun 27 10:21:22 2013 +0100
> +++ b/src/share/classes/java/sql/ResultSet.java	Fri Jun 28 18:09:36 2013 -0400
> @@ -148,7 +148,7 @@
>   public interface ResultSet extends Wrapper, AutoCloseable {
>   
>       /**
> -     * Moves the cursor froward one row from its current position.
> +     * Moves the cursor forward one row from its current position.
>        * A ResultSet cursor is initially positioned
>        * before the first row; the first call to the method
>        * next makes the first row the current row; the
> dhcp-amer-vpn-adc-anyconnect-10-154-144-63:sql lanceandersen$
>
>
> Best
> Lance
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From joe.darcy at oracle.com  Fri Jun 28 23:07:36 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 28 Jun 2013 16:07:36 -0700
Subject: Review needed for ResultSet.next typo bug 8019286
In-Reply-To: 
References: 
Message-ID: <51CE1738.4030007@oracle.com>

Looks fine Lance; approved.

Cheers,

-Joe

On 06/28/2013 03:21 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> Looking for a reviewer for this minor typo in ResultSet.next()
>
> $ hg diff
> diff -r 4e69a7dfbeac src/share/classes/java/sql/ResultSet.java
> --- a/src/share/classes/java/sql/ResultSet.java	Thu Jun 27 10:21:22 2013 +0100
> +++ b/src/share/classes/java/sql/ResultSet.java	Fri Jun 28 18:09:36 2013 -0400
> @@ -148,7 +148,7 @@
>   public interface ResultSet extends Wrapper, AutoCloseable {
>   
>       /**
> -     * Moves the cursor froward one row from its current position.
> +     * Moves the cursor forward one row from its current position.
>        * A ResultSet cursor is initially positioned
>        * before the first row; the first call to the method
>        * next makes the first row the current row; the
> dhcp-amer-vpn-adc-anyconnect-10-154-144-63:sql lanceandersen$
>
>
> Best
> Lance
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From henry.jen at oracle.com  Sat Jun 29 00:58:42 2013
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 28 Jun 2013 17:58:42 -0700
Subject: RFR: 8015315: Stream.concat methods
Message-ID: <51CE3142.60800@oracle.com>

Hi,

Please review the webrev that add concat static method to Stream and
primitive Streams.

http://cr.openjdk.java.net/~henryjen/ccc/8015315.0/webrev/

Cheers,
Henry


From lana.steuck at oracle.com  Sat Jun 29 06:11:14 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:14 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20130629061120.9D40F48683@hg.openjdk.java.net>

Changeset: c68c35f50413
Author:    katleman
Date:      2013-06-20 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/c68c35f50413

Added tag jdk8-b95 for changeset 2cf36f43df36

! .hgtags

Changeset: 3357c2776431
Author:    lana
Date:      2013-06-24 14:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/3357c2776431

Merge


Changeset: 469995a8e974
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/469995a8e974

Added tag jdk8-b96 for changeset 3357c2776431

! .hgtags



From lana.steuck at oracle.com  Sat Jun 29 06:11:14 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:14 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130629061122.88B1748684@hg.openjdk.java.net>

Changeset: b031efa535ad
Author:    katleman
Date:      2013-06-20 10:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b031efa535ad

Added tag jdk8-b95 for changeset cbc9926f5b40

! .hgtags

Changeset: d6bd440ac5b9
Author:    lana
Date:      2013-06-24 14:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d6bd440ac5b9

Merge


Changeset: 1bf1d6ce3042
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1bf1d6ce3042

Added tag jdk8-b96 for changeset d6bd440ac5b9

! .hgtags

Changeset: 90864d892593
Author:    lana
Date:      2013-06-28 19:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/90864d892593

Merge




From lana.steuck at oracle.com  Sat Jun 29 06:11:14 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:14 +0000
Subject: hg: jdk8/tl: 11 new changesets
Message-ID: <20130629061116.8105548682@hg.openjdk.java.net>

Changeset: c961c8972485
Author:    erikj
Date:      2013-06-13 14:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c961c8972485

8014231: --with-alsa configuration options don't add include or lib directories to proper flags
Reviewed-by: tbell

! common/autoconf/spec.gmk.in

Changeset: 0c540b1505e3
Author:    erikj
Date:      2013-06-14 13:30 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0c540b1505e3

8016520: jdk native build does not fail on compilation error on windows
Reviewed-by: tbell

! common/makefiles/NativeCompilation.gmk

Changeset: 0d1e8518c722
Author:    erikj
Date:      2013-06-18 11:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/0d1e8518c722

8014404: Debug flag not added to jdk native compile when --enable-debug is set
Reviewed-by: tbell

! common/autoconf/generated-configure.sh
! common/autoconf/toolchain.m4

Changeset: c0fa87863427
Author:    erikj
Date:      2013-06-18 11:30 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c0fa87863427

8015377: Support using compiler devkits on Linux
Reviewed-by: tbell, dholmes

! common/autoconf/basics.m4
! common/autoconf/build-performance.m4
! common/autoconf/generated-configure.sh
! common/autoconf/libraries.m4
+ common/makefiles/devkit/Makefile
+ common/makefiles/devkit/Tools.gmk

Changeset: 785d07fe3890
Author:    katleman
Date:      2013-06-18 15:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/785d07fe3890

Merge


Changeset: 794cceb5dc82
Author:    katleman
Date:      2013-06-20 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/794cceb5dc82

Added tag jdk8-b95 for changeset 785d07fe3890

! .hgtags

Changeset: d72e765a9fbe
Author:    lana
Date:      2013-06-19 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/d72e765a9fbe

Merge


Changeset: f1010ef2f451
Author:    lana
Date:      2013-06-24 14:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/f1010ef2f451

Merge


Changeset: ebcd79fc658d
Author:    erikj
Date:      2013-06-25 09:37 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ebcd79fc658d

8012564: The SOURCE value in release file of JDK 8 doesn't contain valid changesets for some OS since b74
Reviewed-by: alanb, tbell

! common/makefiles/Main.gmk

Changeset: c156084add48
Author:    katleman
Date:      2013-06-25 13:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c156084add48

Merge

! common/makefiles/Main.gmk

Changeset: 4c363b94ea2a
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4c363b94ea2a

Added tag jdk8-b96 for changeset c156084add48

! .hgtags



From lana.steuck at oracle.com  Sat Jun 29 06:11:17 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:17 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20130629061146.C867F48685@hg.openjdk.java.net>

Changeset: 7de08fa7cb34
Author:    katleman
Date:      2013-06-20 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7de08fa7cb34

Added tag jdk8-b95 for changeset 1468c94135f9

! .hgtags

Changeset: 690d34b326bc
Author:    lana
Date:      2013-06-24 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/690d34b326bc

Merge


Changeset: dcde7f049111
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dcde7f049111

Added tag jdk8-b96 for changeset 690d34b326bc

! .hgtags



From lana.steuck at oracle.com  Sat Jun 29 06:11:18 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:18 +0000
Subject: hg: jdk8/tl/jaxp: 3 new changesets
Message-ID: <20130629061148.0653648686@hg.openjdk.java.net>

Changeset: e68a5d2efcae
Author:    katleman
Date:      2013-06-20 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e68a5d2efcae

Added tag jdk8-b95 for changeset b8c5f4b6f0ff

! .hgtags

Changeset: 6121efd29923
Author:    lana
Date:      2013-06-24 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6121efd29923

Merge


Changeset: 403f882ecc94
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/403f882ecc94

Added tag jdk8-b96 for changeset 6121efd29923

! .hgtags



From lana.steuck at oracle.com  Sat Jun 29 06:11:45 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:45 +0000
Subject: hg: jdk8/tl/hotspot: 46 new changesets
Message-ID: <20130629061349.94F3048688@hg.openjdk.java.net>

Changeset: aaa45012be98
Author:    katleman
Date:      2013-06-20 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaa45012be98

Added tag jdk8-b95 for changeset 5d65c078cd0a

! .hgtags

Changeset: 38e483cb1bcd
Author:    lana
Date:      2013-06-24 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38e483cb1bcd

Merge


Changeset: f9709e27a876
Author:    amurillo
Date:      2013-06-14 07:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9709e27a876

8016567: new hotspot build - hs25-b38
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: a837fa3d3f86
Author:    dcubed
Date:      2013-06-13 11:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a837fa3d3f86

8013057: assert(_needs_gc || SafepointSynchronize::is_at_safepoint()) failed: only read at safepoint
Summary: Detect mmap() commit failures in Linux and Solaris os::commit_memory() impls and call vm_exit_out_of_memory(). Add os::commit_memory_or_exit(). Also tidy up some NMT accounting and some mmap() return value checking.
Reviewed-by: zgu, stefank, dholmes, dsamersoff

! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp

Changeset: 2bffd20a0fcc
Author:    ctornqvi
Date:      2013-06-13 21:57 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2bffd20a0fcc

8016065: Write regression test for 7167142
Summary: Regression tests written for both test cases (.hotspotrc and .hotspot_compiler). Also reviewed by mikhailo.seledtsov at oracle.com
Reviewed-by: zgu, coleenp

+ test/runtime/CommandLine/CompilerConfigFileWarning.java
+ test/runtime/CommandLine/ConfigFileWarning.java

Changeset: 1e9094165098
Author:    ctornqvi
Date:      2013-06-13 22:00 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e9094165098

8015324: Create tests for CDS feature
Summary: Wrote tests for use of CDS with ObjectAlignmentInBytes CL option
Reviewed-by: coleenp, ctornqvi, hseigel
Contributed-by: Mikhailo Seledtsov 

+ test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
+ test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
+ test/testlibrary/com/oracle/java/testlibrary/Platform.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: a0a47b2649a2
Author:    ctornqvi
Date:      2013-06-14 13:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a0a47b2649a2

Merge


Changeset: ef57c43512d6
Author:    ccheung
Date:      2013-06-13 22:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef57c43512d6

8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux
Reviewed-by: dholmes, coleenp
Contributed-by: jeremymanson at google.com, calvin.cheung at oracle.com

! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/ci/ciUtilities.hpp
! src/share/vm/classfile/genericSignatures.cpp
! src/share/vm/classfile/verifier.hpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/prims/forte.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/services/diagnosticArgument.cpp
! src/share/vm/utilities/exceptions.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: bcb96b2922f2
Author:    zgu
Date:      2013-06-14 07:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcb96b2922f2

Merge


Changeset: ab313d4e9a8b
Author:    zgu
Date:      2013-06-14 09:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab313d4e9a8b

8011968: Kitchensink crashed with SIGSEGV in MemBaseline::baseline
Summary: Simple fix to add NULL pointer check that can cause segv
Reviewed-by: coleenp, ctornqvi

! src/share/vm/services/memBaseline.cpp

Changeset: dba2306ee2e3
Author:    zgu
Date:      2013-06-14 07:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dba2306ee2e3

Merge


Changeset: 3aaa16611c30
Author:    zgu
Date:      2013-06-14 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3aaa16611c30

Merge


Changeset: e95fc50106cf
Author:    rdurbin
Date:      2013-06-14 07:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e95fc50106cf

7178026: os::close can restart ::close but that is not a restartable syscall
Summary: Removed restart macros from all os:close calls on Solaris, Linux, MacOS X platforms.
Reviewed-by: dcubed, dholmes

! src/os/bsd/dtrace/jvm_dtrace.c
! src/os/bsd/vm/attachListener_bsd.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/attachListener_linux.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/dtrace/jvm_dtrace.c
! src/os/solaris/vm/attachListener_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp

Changeset: f2d56a269345
Author:    dcubed
Date:      2013-06-14 08:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2d56a269345

Merge


Changeset: c7242a797916
Author:    dcubed
Date:      2013-06-14 19:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7242a797916

Merge


Changeset: 5c89346f2bdd
Author:    sspitsyn
Date:      2013-06-14 15:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c89346f2bdd

6493116: JVMTI Doc: GetOwnedMonitorStackDepthInfo has a typo in monitor_info_ptr parameter description
Summary: A typo in the parameter spelling, a bound update missed when the parameter was renamed
Reviewed-by: sla, minqi
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmti.xml

Changeset: 7fa28f3d3f62
Author:    sspitsyn
Date:      2013-06-14 22:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7fa28f3d3f62

Merge


Changeset: abbd5c660b48
Author:    mgronlun
Date:      2013-06-15 13:17 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abbd5c660b48

8016105: Add complementary RETURN_NULL allocation macros in allocation.hpp
Reviewed-by: sla, rbackman

! src/share/vm/memory/allocation.hpp

Changeset: cd2118b62475
Author:    zgu
Date:      2013-06-10 10:45 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd2118b62475

8013917: Kitchensink crashed with SIGSEGV in BaselineReporter::diff_callsites
Summary: Simple fix when memory allocation site is gone, NMT should report 0 memory size, instead old memory size.
Reviewed-by: dcubed, ctornqvi

! src/share/vm/services/memReporter.cpp

Changeset: ef748153ee8f
Author:    sla
Date:      2013-06-17 18:35 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef748153ee8f

8016304: ThreadMXBean.getDeadlockedThreads reports bogus deadlocks on JDK 8
Reviewed-by: dcubed, mgronlun

! src/share/vm/services/threadService.cpp
+ test/serviceability/threads/TestFalseDeadLock.java

Changeset: 1f4355cee9a2
Author:    zgu
Date:      2013-06-18 08:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f4355cee9a2

8013651: NMT: reserve/release sequence id's in incorrect order due to race
Summary: Fixed NMT race condition for realloc, uncommit and release
Reviewed-by: coleenp, ccheung

! src/os/bsd/vm/os_bsd.cpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: a5904a086d9f
Author:    zgu
Date:      2013-06-18 09:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5904a086d9f

Merge


Changeset: cd54c7e92908
Author:    minqi
Date:      2013-06-18 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd54c7e92908

8015660: Test8009761.java "Failed: init recursive calls: 24. After deopt 25"
Summary: Windows reserves and only partially commits thread stack. For detecting more thread stack space for execution,  Windows installs one-shot page as guard page just before the current commited edge. It will trigger STACK_OVERFLOW_EXCEPTION when lands on last 4 pages of thread stack space. StackYellowPages default value is 2 on Windows (plus 1 page of StackRedPages, 3 pages guarded by hotspot) so the exception happens one page before Yellow pages. Same route executed second time will have one more page brought in, this leads same execution with different stack depth(interpreter mode). We need match Windows settings so the stack overflow exception will not happen before Yellow pages.
Reviewed-by: dholmes
Contributed-by: andreas.schoesser at sap.com

! src/cpu/x86/vm/globals_x86.hpp

Changeset: 726d2d4913fc
Author:    nloodin
Date:      2013-06-19 18:13 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/726d2d4913fc

Merge


Changeset: 0abfeed51c9e
Author:    brutisso
Date:      2013-06-14 08:02 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0abfeed51c9e

8012265: VM often crashes on solaris with a lot of memory
Summary: Increase HeapBaseMinAddress for G1 from 256m to 1g on Solaris x86
Reviewed-by: mgerdin, coleenp, kvn

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp

Changeset: 01522ca68fc7
Author:    johnc
Date:      2013-06-18 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01522ca68fc7

8015237: Parallelize string table scanning during strong root processing
Summary: Parallelize the scanning of the intern string table by having each GC worker claim a given number of buckets. Changes were also reviewed by Per Liden .
Reviewed-by: tschatzl, stefank, twisti

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/memory/sharedHeap.cpp

Changeset: b9d151496930
Author:    brutisso
Date:      2013-06-18 22:45 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9d151496930

8016556: G1: Use ArrayAllocator for BitMaps
Reviewed-by: tschatzl, dholmes, coleenp, johnc

! src/share/vm/memory/allocation.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp

Changeset: 493089fd29df
Author:    poonam
Date:      2013-06-19 06:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/493089fd29df

8015903: Format issue with -XX:+PrintAdaptiveSizePolicy on JDK8
Summary: Missing linebreak in hotspot log.
Reviewed-by: brutisso, tschatzl
Contributed-by: vladimir.kempik at oracle.com

! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp

Changeset: 9f9c0a163cc5
Author:    ehelin
Date:      2013-06-20 10:03 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f9c0a163cc5

Merge

! src/share/vm/memory/allocation.hpp

Changeset: 8d52e305a777
Author:    morris
Date:      2013-06-07 07:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d52e305a777

8015437: SPARC cbcond branch offset out of 10-bit range
Summary: Forced SPARC MacroAssembler eden_alloate to use long branch to slow case
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/macroAssembler_sparc.cpp

Changeset: ea60d1de6735
Author:    kvn
Date:      2013-06-07 11:43 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea60d1de6735

Merge


Changeset: 46c544b8fbfc
Author:    morris
Date:      2013-06-07 16:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46c544b8fbfc

8008407: remove SPARC V8 support
Summary: Removed most of the SPARC V8 instructions
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c2_init_sparc.cpp
! src/cpu/sparc/vm/disassembler_sparc.hpp
! src/cpu/sparc/vm/globals_sparc.hpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/cpu/sparc/vm/nativeInst_sparc.cpp
! src/cpu/sparc/vm/nativeInst_sparc.hpp
! src/cpu/sparc/vm/register_sparc.hpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/stubRoutines_sparc.cpp
! src/cpu/sparc/vm/stubRoutines_sparc.hpp
! 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/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp
! src/os_cpu/solaris_sparc/vm/solaris_sparc.il
! src/share/vm/runtime/arguments.cpp

Changeset: e7f5651d459c
Author:    twisti
Date:      2013-06-11 11:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7f5651d459c

8003268: SharedRuntime::generate_native_wrapper doesn't save all registers across runtime tracing calls for JNI critical native methods
Reviewed-by: kvn

! src/cpu/x86/vm/sharedRuntime_x86_64.cpp

Changeset: 693e4d04fd09
Author:    drchase
Date:      2013-06-11 16:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/693e4d04fd09

8014959: assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit
Summary: Insert extra checks and bailouts for too many nodes
Reviewed-by: kvn

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/matcher.cpp

Changeset: bc8956037049
Author:    kvn
Date:      2013-06-11 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc8956037049

Merge


Changeset: c52abc8a0b08
Author:    drchase
Date:      2013-06-13 15:39 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c52abc8a0b08

8010124: JVM_GetClassContext: use GrowableArray instead of KlassLink
Summary: replace linked data structure with array (performance)
Reviewed-by: kvn
Contributed-by: christian.thalinger at oracle.com, david.r.chase at oracle.com

! src/share/vm/prims/jvm.cpp

Changeset: 7fa25f5575c9
Author:    adlertz
Date:      2013-06-14 01:19 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7fa25f5575c9

8016157: During CTW: C2: assert(!def_outside->member(r)) failed: Use of external LRG overlaps the same LRG defined in this block
Summary: Disable rematerialization for negD node
Reviewed-by: kvn, roland

! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp

Changeset: ac91879aa56f
Author:    kvn
Date:      2013-06-14 16:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac91879aa56f

Merge

- src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/prims/jvm.cpp

Changeset: 87a6f2df28e2
Author:    drchase
Date:      2013-06-17 12:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/87a6f2df28e2

8002160: Compilation issue with adlc using latest SunStudio compilers
Summary: modify declaration of 'swap' overloading; dodge optimizer bug in c1_LIR.cpp
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp
! src/share/vm/c1/c1_LIR.cpp

Changeset: 08d35fd1b599
Author:    adlertz
Date:      2013-06-19 00:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/08d35fd1b599

8001345: VM crashes with assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
Summary: Remove unnecessary LoadN / DecodeN nodes at MemBarAcquire nodes.
Reviewed-by: kvn, roland

! src/share/vm/opto/memnode.cpp

Changeset: b88209cf98c0
Author:    kvn
Date:      2013-06-20 16:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b88209cf98c0

Merge

- src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 2cc5a9d1ba66
Author:    amurillo
Date:      2013-06-21 00:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2cc5a9d1ba66

Merge

- src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp

Changeset: 3bdeff4a6ca7
Author:    amurillo
Date:      2013-06-21 00:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3bdeff4a6ca7

Added tag hs25-b38 for changeset 2cc5a9d1ba66

! .hgtags

Changeset: 9f3e3245b50f
Author:    amurillo
Date:      2013-06-25 12:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f3e3245b50f

Merge

- src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp
- src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jvm.cpp

Changeset: e6a4b8c71fa6
Author:    katleman
Date:      2013-06-26 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e6a4b8c71fa6

8017323: JDK8 b95 source with GPL header errors
Reviewed-by: tbell, darcy

! src/share/vm/memory/referenceProcessorStats.hpp

Changeset: b6d1e42655cd
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6d1e42655cd

Added tag jdk8-b96 for changeset e6a4b8c71fa6

! .hgtags



From lana.steuck at oracle.com  Sat Jun 29 06:11:21 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:11:21 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20130629061220.24BBC48687@hg.openjdk.java.net>

Changeset: 3478b1e81baf
Author:    katleman
Date:      2013-06-20 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3478b1e81baf

Added tag jdk8-b95 for changeset 4cb113623127

! .hgtags

Changeset: b3458329d060
Author:    lana
Date:      2013-06-24 14:27 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b3458329d060

Merge


Changeset: 988aef3a8c3a
Author:    katleman
Date:      2013-06-26 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/988aef3a8c3a

8016684: JDK8 b94 source with GPL header errors
Reviewed-by: tbell, darcy

! test/tools/javac/6567415/T6567415.java

Changeset: 6a11a81a8824
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6a11a81a8824

Added tag jdk8-b96 for changeset 988aef3a8c3a

! .hgtags

Changeset: 66147d50d8d6
Author:    lana
Date:      2013-06-28 19:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/66147d50d8d6

Merge




From lana.steuck at oracle.com  Sat Jun 29 06:13:55 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 29 Jun 2013 06:13:55 +0000
Subject: hg: jdk8/tl/jdk: 34 new changesets
Message-ID: <20130629062118.6CC2F48689@hg.openjdk.java.net>

Changeset: 3531945431aa
Author:    erikj
Date:      2013-06-13 14:04 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3531945431aa

8014231: --with-alsa configuration options don't add include or lib directories to proper flags
Reviewed-by: tbell

! makefiles/CompileNativeLibraries.gmk

Changeset: 42aa9f182885
Author:    katleman
Date:      2013-06-18 15:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42aa9f182885

Merge

! makefiles/CompileNativeLibraries.gmk

Changeset: 0c4db4782114
Author:    katleman
Date:      2013-06-20 10:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c4db4782114

Added tag jdk8-b95 for changeset 42aa9f182885

! .hgtags

Changeset: 616a73e97b38
Author:    bae
Date:      2013-06-06 13:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/616a73e97b38

8013430: REGRESSION: closed/java/awt/color/ICC_Profile/LoadProfileTest/LoadProfileTest.java fails with java.io.StreamCorruptedException: invalid type code: EE since 8b87
Reviewed-by: prr, vadim

! src/share/classes/java/awt/color/ICC_Profile.java
+ src/share/classes/sun/java2d/cmm/ProfileDataVerifier.java

Changeset: 917dd642f934
Author:    bae
Date:      2013-06-07 14:45 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/917dd642f934

6830714: cmm test failures with OpenJDK
Reviewed-by: prr

! test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvDCMTest.java
! test/sun/java2d/cmm/ColorConvertOp/ColConvTest.java

Changeset: 1431488fb0f9
Author:    jgodinez
Date:      2013-06-07 10:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1431488fb0f9

8013810: PrintServiceLookup.lookupPrintServices() does not return consistent result
Reviewed-by: prr, jgodinez
Contributed-by: patrick at reini.net

! src/solaris/classes/sun/print/UnixPrintServiceLookup.java
+ test/javax/print/PrintServiceLookup/GetPrintServices.java

Changeset: f67db3d2f406
Author:    prr
Date:      2013-06-13 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f67db3d2f406

8016485: Windows native print dialog does not reflect default printer settings
Reviewed-by: jgodinez, jchen

! src/windows/classes/sun/awt/windows/WPrinterJob.java
! src/windows/classes/sun/print/Win32PrintService.java
! src/windows/native/sun/windows/WPrinterJob.cpp
! src/windows/native/sun/windows/awt_PrintControl.cpp

Changeset: 82927bc76ea5
Author:    lana
Date:      2013-06-14 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82927bc76ea5

Merge

- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

Changeset: c636942a28ef
Author:    prr
Date:      2013-06-17 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c636942a28ef

8015334: Memory leak when kerning is used on Windows.
Reviewed-by: srl, bae

! src/share/native/sun/font/layout/KernTable.cpp
! src/share/native/sun/font/layout/KernTable.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
+ test/java/awt/font/TextLayout/KerningLeak.java

Changeset: e3d5df92f4ff
Author:    lana
Date:      2013-06-19 17:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3d5df92f4ff

Merge


Changeset: deb8752684e3
Author:    kshefov
Date:      2013-06-06 17:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/deb8752684e3

8015976: OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions
Reviewed-by: serb, anthony

! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html
! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java
! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java

Changeset: cfd3f8bfb96c
Author:    kshefov
Date:      2013-06-06 17:06 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfd3f8bfb96c

7109977: [macosx] MixingInHwPanel.java test fails on Mac trying to click in the reserved corner
Reviewed-by: serb, anthony

! test/java/awt/Mixing/MixingInHwPanel.java

Changeset: cb7f711e1752
Author:    dmarkov
Date:      2013-06-06 17:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb7f711e1752

8015853: java.lang.ArrayIndexOutOfBoundsException when running SwingSet2 demo
Reviewed-by: alexp, serb

! src/share/classes/javax/swing/text/View.java
+ test/javax/swing/text/View/8015853/bug8015853.java
+ test/javax/swing/text/View/8015853/bug8015853.txt

Changeset: 2d5bb70458b6
Author:    kshefov
Date:      2013-06-10 16:44 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d5bb70458b6

7105030: [TEST_BUG] [macosx] The tests never finishes
Reviewed-by: alexsch, serb

+ test/javax/swing/JMenu/4692443/bug4692443.java

Changeset: d14523c12f20
Author:    kshefov
Date:      2013-06-11 14:14 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d14523c12f20

8012569: TEST_BUG: java/awt/GraphicsDevice/CheckDisplayModes.java fails
Reviewed-by: anthony, serb

! test/java/awt/GraphicsDevice/CheckDisplayModes.java

Changeset: 9ab7973d5907
Author:    kshefov
Date:      2013-06-11 14:20 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ab7973d5907

7184908: TEST_BUG: [macosx] closed/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java fails
Reviewed-by: alexsch, serb

+ test/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java

Changeset: 59dc1385127f
Author:    malenkov
Date:      2013-06-11 16:02 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59dc1385127f

8015336: BasicComboBoxEditor throws NullPointerException
Reviewed-by: alexsch

! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java
+ test/javax/swing/plaf/basic/BasicComboBoxEditor/Test8015336.java

Changeset: 7bba0147ab3d
Author:    alexsch
Date:      2013-06-11 16:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bba0147ab3d

8009984: [parfait] Buffer overrun at jdk/src/macosx/native/com/apple/laf/AquaFileView.m
Reviewed-by: serb, art

! src/macosx/native/com/apple/laf/AquaFileView.m

Changeset: 33fc8a062f90
Author:    ant
Date:      2013-06-12 16:18 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33fc8a062f90

8015454: java/awt/Focus/TypeAhead/TestFocusFreeze.java hangs with jdk8 since b56
Reviewed-by: anthony

! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java

Changeset: a7d943998bd3
Author:    pchelko
Date:      2013-06-13 11:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7d943998bd3

8013468: [macosx] Cursor does not update properly when in fullscreen mode on Mac
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m
+ test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java

Changeset: 6e5824a42c49
Author:    alitvinov
Date:      2013-06-13 18:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e5824a42c49

6847588: AWT test fails
Reviewed-by: anthony, serb

! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java

Changeset: d57fa4e45100
Author:    ant
Date:      2013-06-14 16:38 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d57fa4e45100

8014821: Regression: Focus issues with Oracle WebCenter Capture applet
Reviewed-by: leonidr

! src/windows/native/sun/windows/awt_Frame.cpp

Changeset: 3a157a38f9b3
Author:    lana
Date:      2013-06-14 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a157a38f9b3

Merge

- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
- src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

Changeset: a0202d94844a
Author:    malenkov
Date:      2013-06-17 18:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0202d94844a

8013571: TreeModelEvent doesn't accept "null" for root as Javadoc specifies.
Reviewed-by: alexsch

! src/share/classes/javax/swing/JTree.java
! src/share/classes/javax/swing/event/TreeModelEvent.java
! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java
! src/share/classes/sun/swing/SwingUtilities2.java
+ test/javax/swing/JTree/8013571/Test8013571.java

Changeset: 6a3a2cb3ca6a
Author:    malenkov
Date:      2013-06-19 14:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a3a2cb3ca6a

8013442: No file filter selected in file type combo box when using JFileChooser
Reviewed-by: alexsch

! src/share/classes/javax/swing/JFileChooser.java
+ test/javax/swing/JFileChooser/8013442/Test8013442.java

Changeset: e8000751a585
Author:    pchelko
Date:      2013-06-19 17:12 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8000751a585

8005661: [parfait] Possible buffer overrun in jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c
8005695: [parfait] Format string argument mismatch in jdk/src/solaris/native/sun/xawt/XToolkit.c
8005752: [parfait] False positive function call mismatch at jdk/src/solaris/native/sun/xawt/XWindow.c
Reviewed-by: art, serb

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_InputMethod.c
! src/solaris/native/sun/xawt/XToolkit.c

Changeset: a117785457f6
Author:    lana
Date:      2013-06-19 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a117785457f6

Merge


Changeset: aa4610fe8a73
Author:    lana
Date:      2013-06-19 18:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa4610fe8a73

Merge

- make/sun/xawt/ToBin.java
- makefiles/sun/awt/X11/ToBin.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
- src/share/classes/sun/misc/FDBigInt.java
- src/share/classes/sun/misc/Hashing.java
- src/solaris/classes/sun/awt/X11/XIconInfo.java
! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
- src/solaris/classes/sun/awt/X11/security-icon-bw16.png
- src/solaris/classes/sun/awt/X11/security-icon-bw24.png
- src/solaris/classes/sun/awt/X11/security-icon-bw32.png
- src/solaris/classes/sun/awt/X11/security-icon-bw48.png
- src/solaris/classes/sun/awt/X11/security-icon-interim16.png
- src/solaris/classes/sun/awt/X11/security-icon-interim24.png
- src/solaris/classes/sun/awt/X11/security-icon-interim32.png
- src/solaris/classes/sun/awt/X11/security-icon-interim48.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow16.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow24.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow32.png
- src/solaris/classes/sun/awt/X11/security-icon-yellow48.png
! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/windows/native/sun/windows/WPrinterJob.cpp
! src/windows/native/sun/windows/awt_PrintControl.cpp
- test/java/lang/invoke/7196190/MHProxyTest.java
- test/sun/misc/Hashing.java

Changeset: fce2eaa84b21
Author:    lana
Date:      2013-06-24 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce2eaa84b21

Merge


Changeset: 58e5d1149f97
Author:    erikj
Date:      2013-06-25 09:25 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58e5d1149f97

8017480: Move copying of jfr files to closed makefile
Reviewed-by: sla, tbell

! makefiles/CopyFiles.gmk

Changeset: fd41ca58229c
Author:    katleman
Date:      2013-06-25 13:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd41ca58229c

Merge


Changeset: 4a5d3cf2b3af
Author:    katleman
Date:      2013-06-26 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a5d3cf2b3af

8016684: JDK8 b94 source with GPL header errors
Reviewed-by: tbell, darcy

! src/share/classes/java/nio/CharBufferSpliterator.java
! src/share/native/sun/management/DiagnosticCommandImpl.c
! test/java/lang/management/MXBean/MXBeanBehavior.java
! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java

Changeset: 2f1386fc2079
Author:    katleman
Date:      2013-06-27 13:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f1386fc2079

Added tag jdk8-b96 for changeset 4a5d3cf2b3af

! .hgtags

Changeset: b4d36f3717b8
Author:    lana
Date:      2013-06-28 19:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4d36f3717b8

Merge




From lance.andersen at oracle.com  Sat Jun 29 10:13:43 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Sat, 29 Jun 2013 10:13:43 +0000
Subject: hg: jdk8/tl/jdk: 8019286: Fix javadoc typo in ResultSet.next
Message-ID: <20130629101441.607234868D@hg.openjdk.java.net>

Changeset: a4eb59bffb60
Author:    lancea
Date:      2013-06-29 06:12 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4eb59bffb60

8019286: Fix javadoc typo in ResultSet.next
Reviewed-by: darcy, mchung

! src/share/classes/java/sql/ResultSet.java



From peter.levart at gmail.com  Sat Jun 29 11:55:42 2013
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 29 Jun 2013 13:55:42 +0200
Subject: RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info()
	doesn't log without configuration
In-Reply-To: <51C1CEE9.9010200@oracle.com>
References: <51C1CEE9.9010200@oracle.com>
Message-ID: <51CECB3E.2010501@gmail.com>

Hi,

I haven't studied this deeply yet, but maybe somebody knows the answer: 
Why is it necessary to add root and global loggers to LogManager in it's 
static initializer? Global Logger could be created and initialized 
lazily, when 1st requested (in static initialization of Logger class), 
and the root Logger is always "ensured" lazily before any other Logger 
is initialized. If the dependency on Logger class was removed from 
LogManager static initialization, then Logger static/lazy initialization 
could depend on LogManager (either just LogManager.manager field when 
fully configured LogManager is not needed/can't be requested or 
LogManager.getLogManager() for fully configured LogManager) ...

The initialization of LogManager, root & default Loggers is very 
entangled currently and any change to such code can be fragile.

What dou you think of untangling it?

Regards, Peter

On 06/19/2013 05:31 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a proposed fix for:
>
> 7184195 - java.util.logging.Logger.getGlobal().info()
>           doesn't log without configuration
>
> Jim who was the original evaluator of this bug find out
> that the root cause of the issue was that LogManager hadn't been
> initialized yet, and therefore the global Logger returned had its
> manager instance 'null' - and more to the point - had no configuration
> since the configuration is established by the LogManager.
>
> The fix proposed is simple. In getGlobal() we check whether
> the 'manager' variable is null - and if it is, we initialize it
> by calling LogManager.getLogManager().
> This is a pattern which is already present at other places in
> the Logger.java class file.
>
> 
>
> However - initialization of LogManager has proved to be fragile
> in the past - in particular wrt deadlocks between Logger and
> LogManager caused by circular class initialization.
>
> Therefore, I have added two test files TestGetGlobal.java and
> TestGetGlobal2.java which try to trigger such deadlocks by
> calling Logger.getGlobal()
> or Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) before the
> LogManager class is initialized.
>
> The tests have a bunch of @run line trying to do so with
> different configurations, including by using custom LogManager
> subclasses, with and without a security manager on.
>
> I have seen no issue so far.
>
> best regards,
>
> -- daniel



From vicente.romero at oracle.com  Sat Jun 29 19:14:01 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 29 Jun 2013 19:14:01 +0000
Subject: hg: jdk8/tl/langtools: 6983646: javap should identify why a
	DefaultAttribute is being used
Message-ID: <20130629191408.BDE8D48692@hg.openjdk.java.net>

Changeset: 891c5ecb8306
Author:    vromero
Date:      2013-06-29 20:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/891c5ecb8306

6983646: javap should identify why a DefaultAttribute is being used
Reviewed-by: jjg

! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/DefaultAttribute.java
! src/share/classes/com/sun/tools/javap/AttributeWriter.java



From kumar.x.srinivasan at oracle.com  Sun Jun 30 02:02:53 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sat, 29 Jun 2013 19:02:53 -0700
Subject: RFR: 8017463: [TEST_BUG] 2 tests from tools/pack200/ remain about
	1 GB of data in work directory after execution
Message-ID: <51CF91CD.9040901@oracle.com>

Hi,

Please review changes to cleanup the test area after pack200 test
completion. Some tests generally use large jars and a local copy of the 
JDK to
test with, created a generic utility to nuke most of the remains.

The webrev:
http://cr.openjdk.java.net/~ksrini/8017463/webrev.0/

The bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017463

Thanks
Kumar



From nicholas+openjdk at nicholaswilliams.net  Sun Jun 30 21:26:39 2013
From: nicholas+openjdk at nicholaswilliams.net (Nick Williams)
Date: Sun, 30 Jun 2013 16:26:39 -0500
Subject: Error in Javadoc for DatabaseMetaData
Message-ID: <214DD60F-F0B4-4A56-BF6E-A91EF38D283F@nicholaswilliams.net>

In java.sql.DatabaseMetaData, the Javadoc for supportsResultSetHoldability fails to properly close a  tag, and so everything following that method is monospace. To be precise:

ResultSet.CLOSE_CURSORS_AT_COMMIT

However, it should be:

ResultSet.CLOSE_CURSORS_AT_COMMIT

Nick



From joe.darcy at oracle.com  Sun Jun 30 23:02:26 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sun, 30 Jun 2013 23:02:26 +0000
Subject: hg: jdk8/tl/jdk: 8019466: Fix doclint issues in java.util.function
Message-ID: <20130630230251.28759486AD@hg.openjdk.java.net>

Changeset: bf650fee4983
Author:    darcy
Date:      2013-06-30 16:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf650fee4983

8019466: Fix doclint issues in java.util.function
Reviewed-by: briangoetz

! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/UnaryOperator.java



From tbuktu at hotmail.com  Sun Jun 30 23:20:08 2013
From: tbuktu at hotmail.com (Tim Buktu)
Date: Mon, 1 Jul 2013 01:20:08 +0200
Subject: Code update for 8014319: Faster division of large integers
Message-ID: 

Hi,

I made a few changes to the BigInteger code in my GitHub repo:
 * Moved Burnikel-Ziegler division to MutableBigInteger
 * Added more comments to the Burnikel-Ziegler code
 * Updated Barrett thresholds
 * Merged BigInteger.java and BigIntegerTest.java with the latest from hg

The files at the links below contain the latest code for bugs 8014319
and 8014320.
Brian, if you want me to, I can make an updated patch for just 8014319.

https://raw.github.com/tbuktu/bigint/4c24162e99227e177f17f5db9b8ca2757820d2cd/src/main/java/java/math/BigInteger.java
https://raw.github.com/tbuktu/bigint/95f1158d2205614c8739344df07ee35523b8ad89/src/main/java/java/math/MutableBigInteger.java
https://raw.github.com/tbuktu/bigint/95f1158d2205614c8739344df07ee35523b8ad89/src/main/java/java/math/MutableBigInteger.java

Is 8014319 going to be next up for review?
Also, would it be okay to do a s/Reminder/Remainder/g on
MutableBigInteger.java and include it in 8014319?
Thanks,

Tim


From joe.darcy at oracle.com  Sun Jun 30 23:20:45 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 30 Jun 2013 16:20:45 -0700
Subject: JDK 8 code review request for doclint fixes in java.util.jar.Pack200
Message-ID: <51D0BD4D.1050708@oracle.com>

Hello,

Pack200 has some doclint issues; please review the fixes to them below.

Thanks,

-Joe

--- a/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 
16:02:11 2013 -0700
+++ b/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 
16:19:25 2013 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -112,7 +112,7 @@
      // Static methods of the Pack200 class.
      /**
       * Obtain new instance of a class that implements Packer.
-     *
+     * 
            
       * 
          • If the system property java.util.jar.Pack200.Packer
       * is defined, then the value is taken to be the fully-qualified name
       * of a concrete implementation class, which must implement Packer.
@@ -122,6 +122,7 @@
       * 
          • If an implementation has not been specified with the system
       * property, then the system-default implementation class is 
instantiated,
       * and the result is returned.
            • 
+     * 
          
       *
       * 
          Note:  The returned object is not guaranteed to operate
       * correctly if multiple threads use it at the same time.
@@ -137,7 +138,7 @@

      /**
       * Obtain new instance of a class that implements Unpacker.
-     *
+     * 
            
       * 
          • If the system property 
java.util.jar.Pack200.Unpacker
       * is defined, then the value is taken to be the fully-qualified
       * name of a concrete implementation class, which must implement 
Unpacker.
@@ -147,6 +148,7 @@
       * 
          • If an implementation has not been specified with the
       * system property, then the system-default implementation class
       * is instantiated, and the result is returned.
            • 
+     * 
          
       *
       * 
          Note:  The returned object is not guaranteed to operate
       * correctly if multiple threads use it at the same time.
@@ -350,14 +352,14 @@
           * directory will be passed also.
           * 
          
           * Examples:
-         * 
          
+         * 
          {@code
           *     Map p = packer.properties();
           *     p.put(PASS_FILE_PFX+0, "mutants/Rogue.class");
           *     p.put(PASS_FILE_PFX+1, "mutants/Wolverine.class");
           *     p.put(PASS_FILE_PFX+2, "mutants/Storm.class");
           *     # Pass all files in an entire directory hierarchy:
           *     p.put(PASS_FILE_PFX+3, "police/");
-         * 
          .
+         * }
          
           */
          String PASS_FILE_PFX            = "pack.pass.file.";

@@ -378,12 +380,12 @@
           * This is the default value for this property.
           * 
          
           * Examples:
-         * 
          
+         * 
          {@code
           *     Map p = pack200.getProperties();
           *     p.put(UNKNOWN_ATTRIBUTE, ERROR);
           *     p.put(UNKNOWN_ATTRIBUTE, STRIP);
           *     p.put(UNKNOWN_ATTRIBUTE, PASS);
-         * 
          
+         * }
          
           */
          String UNKNOWN_ATTRIBUTE        = "pack.unknown.attribute";



From martinrb at google.com  Sun Jun 30 23:25:48 2013
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 30 Jun 2013 16:25:48 -0700
Subject: RFR 8011427 java.util.concurrent collection Spliterator
	implementations
In-Reply-To: <14D8BCB6-2FF5-4163-8A9B-F76E56C2B199@oracle.com>
References: <14D8BCB6-2FF5-4163-8A9B-F76E56C2B199@oracle.com>
Message-ID: 

Thanks for doing this.  Looks Good To Me.


On Thu, Jun 27, 2013 at 8:33 AM, Paul Sandoz  wrote:

> Hi,
>
> This webrev contains updates of java.util.concurrent collections from 166:
>
>   http://cr.openjdk.java.net/~psandoz/tl/JDK-8011427-concur-splits/webrev/
>
> More specifically:
>
> - spliterator implementations (which are tested by the existing
> spltierator tests).
>
> - various doc updates.
>
> - and other updates that are tricky to separate from the above as
> continual improvements are made, especially to CopyOnWriteArrayList and
> ConcurrentSkipListMap.
>
> ConcurrentHashMap, ConcurrentMap and ConcurrentNavigableMap will be dealt
> with in a separate webrev, as will other aspects of 166.
>
> Most of this code has been in the lambda repo for quite a while (the diff
> between 166 and lambda is much much smaller than the diff between tl and
> lambda). This webrev was derived from the lambda code base after first
> syncing lambda with associated files from 166.
>
> Paul.


From Lance.Andersen at oracle.com  Sun Jun 30 23:31:38 2013
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Sun, 30 Jun 2013 19:31:38 -0400
Subject: JDK 8 code review request for doclint fixes in
	java.util.jar.Pack200
In-Reply-To: <51D0BD4D.1050708@oracle.com>
References: <51D0BD4D.1050708@oracle.com>
Message-ID: 

looks good Joe
On Jun 30, 2013, at 7:20 PM, Joe Darcy wrote:

> Hello,
> 
> Pack200 has some doclint issues; please review the fixes to them below.
> 
> Thanks,
> 
> -Joe
> 
> --- a/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 16:02:11 2013 -0700
> +++ b/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 16:19:25 2013 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -112,7 +112,7 @@
>     // Static methods of the Pack200 class.
>     /**
>      * Obtain new instance of a class that implements Packer.
> -     *
> +     * 
            
>      * 
          • If the system property java.util.jar.Pack200.Packer
>      * is defined, then the value is taken to be the fully-qualified name
>      * of a concrete implementation class, which must implement Packer.
> @@ -122,6 +122,7 @@
>      * 
          • If an implementation has not been specified with the system
>      * property, then the system-default implementation class is instantiated,
>      * and the result is returned.
            • 
> +     * 
          
>      *
>      * 
          Note:  The returned object is not guaranteed to operate
>      * correctly if multiple threads use it at the same time.
> @@ -137,7 +138,7 @@
> 
>     /**
>      * Obtain new instance of a class that implements Unpacker.
> -     *
> +     * 
            
>      * 
          • If the system property java.util.jar.Pack200.Unpacker
>      * is defined, then the value is taken to be the fully-qualified
>      * name of a concrete implementation class, which must implement Unpacker.
> @@ -147,6 +148,7 @@
>      * 
          • If an implementation has not been specified with the
>      * system property, then the system-default implementation class
>      * is instantiated, and the result is returned.
            • 
> +     * 
          
>      *
>      * 
          Note:  The returned object is not guaranteed to operate
>      * correctly if multiple threads use it at the same time.
> @@ -350,14 +352,14 @@
>          * directory will be passed also.
>          * 
          
>          * Examples:
> -         * 
          
> +         * 
          {@code
>          *     Map p = packer.properties();
>          *     p.put(PASS_FILE_PFX+0, "mutants/Rogue.class");
>          *     p.put(PASS_FILE_PFX+1, "mutants/Wolverine.class");
>          *     p.put(PASS_FILE_PFX+2, "mutants/Storm.class");
>          *     # Pass all files in an entire directory hierarchy:
>          *     p.put(PASS_FILE_PFX+3, "police/");
> -         * 
          .
> +         * }
          
>          */
>         String PASS_FILE_PFX            = "pack.pass.file.";
> 
> @@ -378,12 +380,12 @@
>          * This is the default value for this property.
>          * 
          
>          * Examples:
> -         * 
          
> +         * 
          {@code
>          *     Map p = pack200.getProperties();
>          *     p.put(UNKNOWN_ATTRIBUTE, ERROR);
>          *     p.put(UNKNOWN_ATTRIBUTE, STRIP);
>          *     p.put(UNKNOWN_ATTRIBUTE, PASS);
> -         * 
          
> +         * }
          
>          */
>         String UNKNOWN_ATTRIBUTE        = "pack.unknown.attribute";
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com


From kumar.x.srinivasan at oracle.com  Sun Jun 30 23:45:37 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sun, 30 Jun 2013 16:45:37 -0700
Subject: JDK 8 code review request for doclint fixes in
	java.util.jar.Pack200
In-Reply-To: <51D0BD4D.1050708@oracle.com>
References: <51D0BD4D.1050708@oracle.com>
Message-ID: <51D0C321.90409@oracle.com>

Hi Joe,

The changes looks good, thanks for doing this!. I should've peeked at
the generated reports. :-[

But, there are 2 more errors j.u.j.Attributes.java and some missing
@throws for j.u.j.JarEntry.java, are you planning on doing this separately ?

Thanks

Kumar


> Hello,
>
> Pack200 has some doclint issues; please review the fixes to them below.
>
> Thanks,
>
> -Joe
>
> --- a/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 
> 16:02:11 2013 -0700
> +++ b/src/share/classes/java/util/jar/Pack200.java    Sun Jun 30 
> 16:19:25 2013 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -112,7 +112,7 @@
>      // Static methods of the Pack200 class.
>      /**
>       * Obtain new instance of a class that implements Packer.
> -     *
> +     * 
            
>       * 
          • If the system property 
> java.util.jar.Pack200.Packer
>       * is defined, then the value is taken to be the fully-qualified 
> name
>       * of a concrete implementation class, which must implement Packer.
> @@ -122,6 +122,7 @@
>       * 
          • If an implementation has not been specified with the 
> system
>       * property, then the system-default implementation class is 
> instantiated,
>       * and the result is returned.
            • 
> +     * 
          
>       *
>       * 
          Note:  The returned object is not guaranteed to operate
>       * correctly if multiple threads use it at the same time.
> @@ -137,7 +138,7 @@
>
>      /**
>       * Obtain new instance of a class that implements Unpacker.
> -     *
> +     * 
            
>       * 
          • If the system property 
> java.util.jar.Pack200.Unpacker
>       * is defined, then the value is taken to be the fully-qualified
>       * name of a concrete implementation class, which must implement 
> Unpacker.
> @@ -147,6 +148,7 @@
>       * 
          • If an implementation has not been specified with the
>       * system property, then the system-default implementation class
>       * is instantiated, and the result is returned.
            • 
> +     * 
          
>       *
>       * 
          Note:  The returned object is not guaranteed to operate
>       * correctly if multiple threads use it at the same time.
> @@ -350,14 +352,14 @@
>           * directory will be passed also.
>           * 
          
>           * Examples:
> -         * 
          
> +         * 
          {@code
>           *     Map p = packer.properties();
>           *     p.put(PASS_FILE_PFX+0, "mutants/Rogue.class");
>           *     p.put(PASS_FILE_PFX+1, "mutants/Wolverine.class");
>           *     p.put(PASS_FILE_PFX+2, "mutants/Storm.class");
>           *     # Pass all files in an entire directory hierarchy:
>           *     p.put(PASS_FILE_PFX+3, "police/");
> -         * 
          .
> +         * }
          
>           */
>          String PASS_FILE_PFX            = "pack.pass.file.";
>
> @@ -378,12 +380,12 @@
>           * This is the default value for this property.
>           * 
          
>           * Examples:
> -         * 
          
> +         * 
          {@code
>           *     Map p = pack200.getProperties();
>           *     p.put(UNKNOWN_ATTRIBUTE, ERROR);
>           *     p.put(UNKNOWN_ATTRIBUTE, STRIP);
>           *     p.put(UNKNOWN_ATTRIBUTE, PASS);
> -         * 
          
> +         * }
          
>           */
>          String UNKNOWN_ATTRIBUTE        = "pack.unknown.attribute";
>



From dlloyd at redhat.com  Tue Jun 25 21:59:26 2013
From: dlloyd at redhat.com (David Lloyd)
Date: Tue, 25 Jun 2013 17:59:26 -0400 (EDT)
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9F5D6.2090207@gmail.com>
References: <51C9760F.7000007@gmail.com> <51C9EE5B.8050300@oracle.com>
	<51C9F5D6.2090207@gmail.com>
Message-ID: 

I would say the opposite is true; the Class is safe but the ClassLoader is privileged.  Getting a ClassLoader from a Class requires a security permission when a security manager is present.

--
- DML


On Jun 25, 2013, at 8:57 PM, Peter Levart  wrote:

> 
> On 06/25/2013 09:24 PM, Mandy Chung wrote:
>>> I'm asking here, to hear any arguments against making such API supported and public. Are there any security or other issues? If there aren't, what steps should be taken to introduce such API in the JDK8 timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving @CallerSensitive to a supported package + enabling it to mark methods in any class (not just system and ext classes)...
>> 
>> Besides providing a method returning the caller's class, I'd like to consider what other options we have and different use cases could be satisfied by different API.  For #2, the problem is that the API to find a resource, it requires to use the ClassLoader with the right visibility (the caller's class loader).  This is similiar to 8013839 : Enhance Logger API for handling of resource bundles [1].  For example, a static method Class.getResource to use the caller's class loader to find the given resource might be an alternative?
> 
> Might be enough sometimes, but usually the ClassLoader is not enough, since the location of resources (resource path) might be determined by caller's class name or package (relative to caller's class, for example). So perhaps, if j.l.Class object is to security sensitive, a tuple (caller ClassLoader, caller class name) might be enough for #2 usages.
> 
> Regards, Peter
> 


From dlloyd at redhat.com  Tue Jun 25 22:04:01 2013
From: dlloyd at redhat.com (David Lloyd)
Date: Tue, 25 Jun 2013 18:04:01 -0400 (EDT)
Subject: @CallerSensitive as public API ?
In-Reply-To: <51C9EE5B.8050300@oracle.com>
References: <51C9760F.7000007@gmail.com> <51C9EE5B.8050300@oracle.com>
Message-ID: 

We have a use case within our security manager implementation that *can* be solved with the existing getClassContext method, which returns the whole stack, except we don't *need*  the whole stack, just one specific frame.  Maybe SecurityManager is a good place for this API?

As an aside, getClassContext returns a Class[]; maybe it should be changed to Class[] instead.

--
- DML


On Jun 25, 2013, at 8:35 PM, Mandy Chung  wrote:

> On 6/25/13 3:50 AM, Peter Levart wrote:
>> Hi,
>> 
>> I know that @CallerSensitive annotation was introduced to bring some order to JDK internal plumbings. It's scope was to support JDK internal usage, so it's use is limited to classes loaded by bootstrap or extension class-loaders. In JDK-internal code it is used mainly for implementing security-sensitive decisions. But since the sun.reflect.Reflection.getCallerClass(int) was public and unrestricted, it found it's way out into user code, where at least I know that it is used in two areas:
>> 
>> 1 - to locate callers in the whole call-stack so that their location in class-path can be reported (Log4J is an example)
>> 2 - to locate immediate caller so that some resources associated with it can be located and used (for example localization data in GUI applications)
>> 
>> I don't know how wide-spread 1st usecase is, but the 2nd is common, since it's use enables APIs that need not explicitly pass-in the calling class in order to locate resources associated with it (and/or the class-loader of it). So it would be nice to have such supported API in JDK8 at least.
> 
> It's good to know these use cases.  We leave the method in 7 update release so as to allow time for applications to transition and also determine any use case that the SE API should provide if there is no replacement for it.
> 
>> I'm asking here, to hear any arguments against making such API supported and public. Are there any security or other issues? If there aren't, what steps should be taken to introduce such API in the JDK8 timeframe? I'm thinking of a no-arg method, say j.l.Class.getCaller() and moving @CallerSensitive to a supported package + enabling it to mark methods in any class (not just system and ext classes)...
> 
> Besides providing a method returning the caller's class, I'd like to consider what other options we have and different use cases could be satisfied by different API.  For #2, the problem is that the API to find a resource, it requires to use the ClassLoader with the right visibility (the caller's class loader).  This is similiar to 8013839 : Enhance Logger API for handling of resource bundles [1]. For example, a static method Class.getResource to use the caller's class loader to find the given resource might be an alternative?
> 
> About the timeframe, the API freeze date [2] is Oct 10.  If the API is simple and small effort (test development, security assessement, etc), there is chance to get that in for jdk8.
> 
> Mandy
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8013839
> [2] http://openjdk.java.net/projects/jdk8/milestones#API_Interface_Freeze
>