April 2016 - core-libs-dev

RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"
by Felix Yang 15 Apr '16

15 Apr '16

Hi all, please review the fix for two tests under "test/sample/". Bug: https://bugs.openjdk.java.net/browse/JDK-8151352 Webrev: http://cr.openjdk.java.net/~xiaofeya/8151352/webrev.00/ Original declaration, "@library ../../../src/sample...", is invalid with the latest change in jtreg. See https://bugs.openjdk.java.net/browse/CODETOOLS-7901585. This fix doesn't resolve dependency to "src/sample", but only converts them into testng tests and declares "external.lib.roots" to avoid dot-dot. Thanks, Felix

5 7

RFR: JDK-8147460: Clean-up jrtfs implementation
by Xueming Shen 15 Apr '16

15 Apr '16

Hi, Please hep review the cleanup changes for jrtfs implementation. issue: https://bugs.openjdk.java.net/browse/JDK-8147460 webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev Simple benchmark [1] has been run both on jimage and the "exploded modules" directory, the numbers suggest we also get an encouraging performance boost on most of the frequently invoked access methods. [1] http://cr.openjdk.java.net/~sherman/8147460/MyBenchmark.java Benchmark Mode Cnt Score Error Units ------------------------------------------------------------ [jimage/existing] MyBenchmark.testExists avgt 50 18.592 ± 1.213 ms/op MyBenchmark.testIsDirectory avgt 50 17.382 ± 1.178 ms/op MyBenchmark.testIsRegularFile avgt 50 18.576 ± 1.577 ms/op MyBenchmark.testItr avgt 50 58.414 ± 1.638 ms/op MyBenchmark.testLookupPath avgt 50 18.935 ± 1.093 ms/op MyBenchmark.testLookupStr avgt 50 38.597 ± 1.663 ms/op MyBenchmark.testToRealPath avgt 50 30.119 ± 1.196 ms/op [jimage/new] MyBenchmark.testExists avgt 50 10.865 ± 1.125 ms/op MyBenchmark.testIsDirectory avgt 50 11.077 ± 1.101 ms/op MyBenchmark.testIsRegularFile avgt 50 10.967 ± 1.220 ms/op MyBenchmark.testItr avgt 50 49.249 ± 3.753 ms/op MyBenchmark.testLookupPath avgt 50 10.857 ± 1.071 ms/op MyBenchmark.testLookupStr avgt 50 34.367 ± 1.341 ms/op MyBenchmark.testToRealPath avgt 50 11.460 ± 1.081 ms/op ------------------------------------------------------------ [exploded dir/existing] MyBenchmark.testExists avgt 50 23.055 ± 1.707 ms/op MyBenchmark.testIsDirectory avgt 50 23.985 ± 1.593 ms/op MyBenchmark.testIsRegularFile avgt 50 24.200 ± 1.744 ms/op MyBenchmark.testItr avgt 50 210.002 ± 6.954 ms/op MyBenchmark.testLookupPath avgt 50 23.242 ± 1.799 ms/op MyBenchmark.testLookupStr avgt 50 43.026 ± 1.751 ms/op MyBenchmark.testToRealPath avgt 50 56.536 ± 1.679 ms/op [exploded dir/new] MyBenchmark.testExists avgt 50 11.260 ± 1.209 ms/op MyBenchmark.testIsDirectory avgt 50 11.702 ± 1.069 ms/op MyBenchmark.testIsRegularFile avgt 50 12.284 ± 1.333 ms/op MyBenchmark.testItr avgt 50 49.342 ± 1.516 ms/op MyBenchmark.testLookupPath avgt 50 11.041 ± 1.051 ms/op MyBenchmark.testLookupStr avgt 50 35.850 ± 1.618 ms/op MyBenchmark.testToRealPath avgt 50 13.016 ± 1.339 ms/op Thanks, Sherman

4 10

RFR(S): 8150956: j.l.i.MethodHandles.whileLoop(...) and .iteratedLoop(...) throw unexpected exceptions in the case of 'init' return type is void
by Michael Haupt 15 Apr '16

15 Apr '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150956 Webrev: http://cr.openjdk.java.net/~mhaupt/8150956/webrev.00/ 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

RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe
by Claes Redestad 15 Apr '16

15 Apr '16

Hi, BufferedInputStream is loaded early, and uses AtomicReferenceFieldUpdater to provide CAS functionality to allow for closing streams asynchronously. Using Unsafe directly instead does the exact same thing in the end, but avoids loading a few (4) classes and thus brings us a small startup improvement. Bug: https://bugs.openjdk.java.net/browse/JDK-8153334 Webrev: http://cr.openjdk.java.net/~redestad/8153334/webrev.01/ Thanks! /Claes

10 25

Fwd: How do I import a sun.* class in jshell
by Wang Weijun 15 Apr '16

15 Apr '16

Does anyone here know the answer? It will be quite useful for me if I am either authoring an internal class or using it when implementing a public API. Thanks Max > Begin forwarded message: > > From: Wang Weijun <weijun.wang(a)oracle.com> > Subject: How do I import a sun.* class in jshell > Date: April 13, 2016 at 5:22:02 PM GMT+8 > To: kulla-dev(a)openjdk.java.net > > > $ jshell -J-XaddExports:java.base/sun.security.provider=ALL-UNNAMED > | Welcome to JShell -- Version 9-internal > | Type /help for help > > -> import sun.security.provider.SecureRandom > | Error: > | package sun.security.provider does not exist > | import sun.security.provider.SecureRandom; > | ^--------------------------------^ > > Thanks > Max >

1 0

RFR: 8154212: launcher SEGV when _JAVA_LAUNCHER_DEBUG is set
by Kumar Srinivasan 14 Apr '16

14 Apr '16

Hi Alan, Adds the missing name in the launchModeNames array purely for display/debugging purposes. Please review: http://cr.openjdk.java.net/~ksrini/8154212/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154212 Thanks Kumar PS: running jprt tests in parallel.

3 2

(Round 2) RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all
by Thomas Stüfe 14 Apr '16

14 Apr '16

Hi all, https://bugs.openjdk.java.net/browse/JDK-8150460 thanks to all who took the time to review the first version of this fix! This is the new version: http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webr… I reworked the fix, trying to add in all the input I got: This fix uses a simple one-dimensional array, preallocated at startup, for low-value file descriptors. Like the code did before. Only for large values of file descriptors it switches to an overflow table, organized as two dimensional sparse array of fixed sized slabs, which are allocated on demand. Only the overflow table is protected by a lock. For 99% of all cases we will be using the plain simple fdTable structure as before. Only for unusually large file descriptor values we will be using this overflow table. Memory footprint is kept low: for small values of RLIMIT_NOFILE, we will only allocate as much space as we need. Only if file descriptor values get large, memory is allocated in the overflow table. Note that I avoided the proposed double-checked locking solution: I find it too risky in this place and also unnecessary. When calling getFdEntry(), we will be executing a blocking IO operation afterwards, flanked by two mutex locks (in startOp and endOp). So, I do not think the third mutex lock in getFdEntry will add much, especially since it is only used in case of larger file descriptor values. I also added the fix to bsd_close.c and aix_close.c. I do not like this code triplication. I briefly played around with unifying this code, but this is more difficult than it seems: implementations subtly differ between the three platforms, and solaris implementation is completely different. It may be a worthwhile cleanup, but that would be a separate issue. I did some artificial tests to check how the code does with many and large file descriptor values, all seemed to work well. I also ran java/net jtreg tests on Linux and AIX. Kind Regards, Thomas

3 9

RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported
by Chris Hegarty 14 Apr '16

14 Apr '16

This review is for the second significant part of the changes for JEP 260 [1]. When created, the jdk.unsupported module [2] initially contained the sun.misc package. This issue is will move all the non-Critical APIs out of sun.reflect, leaving only the critical ones, at which point sun.reflect can be moved to the jdk.unsupported module. http://cr.openjdk.java.net/~chegar/8137058/ https://bugs.openjdk.java.net/browse/JDK-8137058 Summary of the changes: - Move all existing sun.reflect types to jdk.internal.reflect, and fix up references in the libraries, and the VM, to use the new internal location. - Update tests, as appropriate, to use the new location. - Add the minimal set of critical APIs to jdk.unsupported/sun.reflect. These ultimately delegate to the internal versions. Additionally, a few new tests have been added to exercise these. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8153737

6 11

Fwd: RFR: JDK-8147460: Clean-up jrtfs implementation
by Xueming Shen 14 Apr '16

14 Apr '16

[re-post, including jigsaw list] Hi, Please hep review the cleanup changes for jrtfs implementation. issue: https://bugs.openjdk.java.net/browse/JDK-8147460 webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev Simple benchmark [1] has been run both on jimage and the "exploded modules" directory, the numbers suggest we also get an encouraging performance boost on most of the frequently invoked access methods. [1] http://cr.openjdk.java.net/~sherman/8147460/MyBenchmark.java Benchmark Mode Cnt Score Error Units ------------------------------------------------------------ [jimage/existing] MyBenchmark.testExists avgt 50 18.592 ± 1.213 ms/op MyBenchmark.testIsDirectory avgt 50 17.382 ± 1.178 ms/op MyBenchmark.testIsRegularFile avgt 50 18.576 ± 1.577 ms/op MyBenchmark.testItr avgt 50 58.414 ± 1.638 ms/op MyBenchmark.testLookupPath avgt 50 18.935 ± 1.093 ms/op MyBenchmark.testLookupStr avgt 50 38.597 ± 1.663 ms/op MyBenchmark.testToRealPath avgt 50 30.119 ± 1.196 ms/op [jimage/new] MyBenchmark.testExists avgt 50 10.865 ± 1.125 ms/op MyBenchmark.testIsDirectory avgt 50 11.077 ± 1.101 ms/op MyBenchmark.testIsRegularFile avgt 50 10.967 ± 1.220 ms/op MyBenchmark.testItr avgt 50 49.249 ± 3.753 ms/op MyBenchmark.testLookupPath avgt 50 10.857 ± 1.071 ms/op MyBenchmark.testLookupStr avgt 50 34.367 ± 1.341 ms/op MyBenchmark.testToRealPath avgt 50 11.460 ± 1.081 ms/op ------------------------------------------------------------ [exploded dir/existing] MyBenchmark.testExists avgt 50 23.055 ± 1.707 ms/op MyBenchmark.testIsDirectory avgt 50 23.985 ± 1.593 ms/op MyBenchmark.testIsRegularFile avgt 50 24.200 ± 1.744 ms/op MyBenchmark.testItr avgt 50 210.002 ± 6.954 ms/op MyBenchmark.testLookupPath avgt 50 23.242 ± 1.799 ms/op MyBenchmark.testLookupStr avgt 50 43.026 ± 1.751 ms/op MyBenchmark.testToRealPath avgt 50 56.536 ± 1.679 ms/op [exploded dir/new] MyBenchmark.testExists avgt 50 11.260 ± 1.209 ms/op MyBenchmark.testIsDirectory avgt 50 11.702 ± 1.069 ms/op MyBenchmark.testIsRegularFile avgt 50 12.284 ± 1.333 ms/op MyBenchmark.testItr avgt 50 49.342 ± 1.516 ms/op MyBenchmark.testLookupPath avgt 50 11.041 ± 1.051 ms/op MyBenchmark.testLookupStr avgt 50 35.850 ± 1.618 ms/op MyBenchmark.testToRealPath avgt 50 13.016 ± 1.339 ms/op Thanks, Sherman

2 1

RFR(S): 8150824: Exceptions when omitting trailing arguments in cleanup
by Michael Haupt 14 Apr '16

14 Apr '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8150824 Webrev: http://cr.openjdk.java.net/~mhaupt/8150824/webrev.00/ The actual bug was fixed with the push for 8150829; this change merely contributes tests for the issue. 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