August 2016 - core-libs-dev

RFR: 8164451: Generate all zero and identity forms at link time
by Claes Redestad 19 Aug '16

19 Aug '16

Hi, after the internal improvements in JDK-8164451, adding pre-generation of zero and identity forms turns out to be very trivial. Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8164451 This removes runtime generation of 2 classes from the test in JDK-8086045, leaving only 2 generated forms to deal with to get down to no(!) bytecode generation during java.lang.invoke bootstrap. Thanks! /Claes

4 3

RFR(S): 8164102: MethodHandles.countedLoop/4 works incorrect for start/end = Integer.MAX_VALUE
by Michael Haupt 19 Aug '16

19 Aug '16

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8164102 Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/ The countedLoop implementation would yield loops with wrong iteration counts if start and end values around the fringes of the int value space were chosen. The fix - passing the decremented counter value to the predicate as well as the body - is temporary, as a larger overhaul of the JEP 274 API is under way as part of the fix to JDK-8151179. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 1

[jdk9] RFR: 8163517: Various cleanup in java.io code
by Ivan Gerasimov 18 Aug '16

18 Aug '16

Hello! Here's a cleanup pass through the code in java.io package. Would you please help review? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163517 WEBREV: http://cr.openjdk.java.net/~igerasim/8163517/00/webrev/ With kind regards, Ivan

4 9

RFR 8138661, Address DataSource javadoc typo
by Lance Andersen 18 Aug '16

18 Aug '16

Hi all, This is a trivial fix of a typo in DataSource --------------------------------- ljanders-mac:jdk ljanders$ hg diff diff -r 6f5da13861db src/java.sql/share/classes/javax/sql/DataSource.java --- a/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 16:27:15 2016 +0300 +++ b/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 14:05:10 2016 -0400 @@ -64,7 +64,7 @@ * <P> * A driver that is accessed via a {@code DataSource} object does not * register itself with the {@code DriverManager}. Rather, a - * {@code DataSource} object is retrieved though a lookup operation + * {@code DataSource} object is retrieved through a lookup operation * and then used to create a {@code Connection} object. With a basic * implementation, the connection obtained through a {@code DataSource} * object is identical to a connection obtained through the ljanders-mac:jdk ljanders$ --------------------------------- Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com <mailto:Lance.Andersen@oracle.com>

2 1

RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle
by Claes Redestad 18 Aug '16

18 Aug '16

Hi, please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the DirectMethodHandles we already pre-generate during linking. webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ bug: https://bugs.openjdk.java.net/browse/JDK-8164044 This also includes some cleanup suggested by Vladimir during internal review, such as: - adding an enum to control this behavior, which allows removing the special version of LF.compileToBytecode introduced by JDK-8163369 - refactored resolution of pregenerated code to the InvokerBytecodeGenerator - removing reliance on the LF.debugName (which we have some loose ideas to remove from LF and tuck away in a map we only create and initialize when actually debugging). This patch removes 11 out of the 39 classes generated on first use of the StringConcatFactory in a simple test, amounting to a ~10ms speedup on my machine. Thanks! /Claes

4 7

RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work
by Yasumasa Suenaga 18 Aug '16

18 Aug '16

Hi all, This review request is related to [1]. jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. However, these tool might be used by JDK developers. So I think we should fix this issue. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8164326/webrev.00/ Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042995.html

3 2

Error at jrt*.js
by Yasumasa Suenaga 18 Aug '16

18 Aug '16

Hi all, I tried to run jrtfsviewer.js and jrtls.js . But they did not work as below: ---------------- $ jjs -fx jrtfsviewer.js Exception in Application start method Exception in thread "main" java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(javafx.graphics@9-ea/LauncherImpl.java:897) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(javafx.graphics@9-ea/LauncherImpl.java:188) at java.lang.Thread.run(java.base@9-ea/Thread.java:843) Caused by: java.lang.NullPointerException at java.util.Objects.requireNonNull(java.base@9-ea/Objects.java:221) at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(java.base@9-ea/JrtFileSystemProvider.java:104) at java.nio.file.FileSystems.newFileSystem(java.base@9-ea/FileSystems.java:342) at jdk.nashorn.internal.scripts.Script$Recompilation$22$3116$jrtfsviewer$cu1$restOf.getJrtFileSystem(jdk.scripting.nashorn.scripts/jrtfsviewer.js:103) at jdk.nashorn.internal.scripts.Script$Recompilation$17$3748A$jrtfsviewer.start(jdk.scripting.nashorn.scripts/jrtfsviewer.js:109) at jdk.nashorn.internal.scripts.Script$Recompilation$6$839A$\=fx\!bootstrap$cu1$restOf.start(jdk.scripting.nashorn.scripts/fx:bootstrap.js:57) at jdk.nashorn.javaadapters.javafx_application_Application.start(Unknown Source) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(javafx.graphics@9-ea/LauncherImpl.java:843) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(javafx.graphics@9-ea/PlatformImpl.java:452) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(javafx.graphics@9-ea/PlatformImpl.java:421) at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(javafx.graphics@9-ea/PlatformImpl.java:420) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(javafx.graphics@9-ea/InvokeLaterDispatcher.java:96) at com.sun.glass.ui.win.WinApplication._runLoop(javafx.graphics@9-ea/Native Method) at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(javafx.graphics@9-ea/WinApplication.java:189) ... 1 more ---------------- $ jjs jrtls.js jrtls.js:37:1 Expected an operand but found * */ ^ ---------------- These scripts are not in JDK. I guess they are used for checking JDK/JRE modules by JDK developers, and they are no longer used. So I'm not sure whether they should be fixed. I think they can be fixed as below: ---------------- diff -r b60dcba6b4f9 src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js Tue Aug 16 09:57:50 2016 +0200 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js Wed Aug 18 20:41:25 2016 +0900 @@ -53,6 +53,7 @@ var Files = Java.type("java.nio.file.Files"); var System = Java.type("java.lang.System"); var URI = Java.type("java.net.URI"); +var Collections = Java.type("java.util.Collections"); // JavaFX classes used var StackPane = Java.type("javafx.scene.layout.StackPane"); @@ -100,7 +101,7 @@ print("did you miss specifying jrt-fs.jar with -cp option?"); usage(); } - return FileSystems.newFileSystem(uri, null, cls.classLoader); + return FileSystems.newFileSystem(uri, Collections.emptyMap(), cls.classLoader); } } diff -r b60dcba6b4f9 src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js --- a/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Tue Aug 16 09:57:50 2016 +0200 +++ b/src/java.base/share/classes/jdk/internal/jrtfs/jrtls.js Wed Aug 18 20:41:25 2016 +0900 @@ -34,7 +34,6 @@ * but also compiled and delivered as part of the jrtfs.jar to support access * to the jimage file provided by the shipped JDK by tools running on JDK 8. */ - */ // classes used var Files = Java.type("java.nio.file.Files"); ---------------- If this fix should be merged, I'll file it to JBS and upload webrev. What do you think about it? Thanks, Yasumasa

2 1

RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions
by Aleks Efimov 18 Aug '16

18 Aug '16

Hi, Please, help to review the fix for memory leak [1] in com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused by usage of static final exceptions. This problem was already fixed in Apache Xerces project [2] and I would like to backport it to JDK9 Xerces implementation. Webrev with the changes: http://cr.openjdk.java.net/~aefimov/8146961/9/00 The Tomcat reproducer attached to the bug report fails without the fix and passes with the fix. The JPRT and JCK testing shows no jaxp tests failures with the proposed fix. With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8146961 [2] https://issues.apache.org/jira/browse/XERCESJ-1667

5 9

Collectors.toSet() small performance improvement
by Tagir F. Valeev 17 Aug '16

17 Aug '16

Hello! I'd like to propose a simple performance patch for Collectors.toSet(): --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 02 07:19:06 2016 +0530 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue Aug 09 11:47:20 2016 +0700 @@ -295,7 +295,12 @@ public static <T> Collector<T, ?, Set<T>> toSet() { return new CollectorImpl<>((Supplier<Set<T>>) HashSet::new, Set::add, - (left, right) -> { left.addAll(right); return left; }, + (left, right) -> { + if (left.size() < right.size()) { + right.addAll(left); return right; + } + left.addAll(right); return left; + }, CH_UNORDERED_ID); } This will add the smaller set to the larger which may improve parallel performance when subtasks produced uneven results. In normal case the additional overhead is insignificant (additional HashSet size comparison per each combine operation which usually performed ~4*parallelism times). Here's simple JDK benchmark with results (Core-i7-4702MQ 4 HT cores, Win7, JDK 9-ea+129 64bit) which confirms the speedup: http://cr.openjdk.java.net/~tvaleev/patches/toSet/ When data is unevenly distributed, it's significantly faster: Original: ToSet.toSetParallel 10000 true avgt 50 88,580 ± 0,874 us/op ToSet.toSetParallel 100000 true avgt 50 676,243 ± 41,188 us/op ToSet.toSetParallel 1000000 true avgt 50 9126,399 ± 83,260 us/op Patched: ToSet.toSetParallel 10000 true avgt 50 62,121 ± 1,207 us/op ToSet.toSetParallel 100000 true avgt 50 556,968 ± 37,404 us/op ToSet.toSetParallel 1000000 true avgt 50 6572,372 ± 183,466 us/op When data is evenly distributed, no statistically significant changes observed: Original: ToSet.toSetParallel 10000 false avgt 50 177,137 ± 5,941 us/op ToSet.toSetParallel 100000 false avgt 50 2056,332 ± 87,433 us/op ToSet.toSetParallel 1000000 false avgt 50 51864,198 ± 560,883 us/op Patched: ToSet.toSetParallel 10000 false avgt 50 172,606 ± 7,321 us/op ToSet.toSetParallel 100000 false avgt 50 1922,478 ± 79,593 us/op ToSet.toSetParallel 1000000 false avgt 50 52648,100 ± 621,526 us/op What do you think? Should I open an issue? With best regards, Tagir Valeev.

3 6

RFR 9 7180225 : SecurityExceptions not defined in some class loader methods
by Brent Christian 17 Aug '16

17 Aug '16

Hi, Please review this change which does some cleanup around documenting conditions for throwing SecurityExceptions. It adds a missing @throws tag to Class.forName(String, boolean, ClassLoader), and consolidates specifics in the @throws tags of ClassLoader & Thread. Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ Specdiff: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/specdiff/package-sum… Thanks! -Brent

3 3