December 2017 - core-libs-dev

8193758: Update copyright headers of files in src tree that are missing "Classpath" exception
by Alan Bateman 18 Dec '17

18 Dec '17

There are a small number of files in jdk/jdk10 that have the GPL header rather than the GPL and "Classpath" exception. This came up last week on jdk-dev. I need a Reviewer to adjust these files. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/8193758/webrev/ There are a few other tools used in the build that may need to be adjusted too. If needed, there will be a follow-up issue for those. -Alan

6 5

[10] RFR: 8193507: [REDO] Startup regression due to JDK-8185582
by Claes Redestad 18 Dec '17

18 Dec '17

Hi, my previous fix failed due to use of non-static inner classes which kept the cleanable objects around. Also, Sherman suggested a more thorough fix to Inflater/Deflater after I had already pushed. Webrev: http://cr.openjdk.java.net/~redestad/8193507/open.00/ Verified all java/util/zip tests pass this time. /Claes

6 16

FW: RFR(M): 8189102: All tools should support -?, -h and --help
by Lindenmaier, Goetz 18 Dec '17

18 Dec '17

Hi, ... missed some lists in my first post ... I prepared a fifth webrev for this change. Please review. It incorporates the changes requested by the CSR reviewers (not to remove docuemtation of '-help' where is was documented before) and the changes proposed by Kumar: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/ See also the information in the webrev itself, there are also patch files with the incremental builds. This change contains fixes for some langtool tests. I ran the following test suites on it: hotspot, jdk, langtools, nashorn, jaxp, most of them on all the platforms we build. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 11. Oktober 2017 22:07 > To: hotspot-dev developers <hotspot-dev(a)openjdk.java.net> > Subject: RFR(M): 8189102: All tools should support -?, -h and --help > > Hi > > The tools in jdk should all show the same behavior wrt. help flags. > This change normalizes the help flags of a row of the tools in the jdk. > Java accepts -?, -h and --help, thus I changed the tools to support > these, too. Some tools exited with '1' after displaying the help message, > I turned this to '0'. > > Maybe this is not the right mailing list for this, please advise. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/ > > In detail, this fixes the help message of the following tools: > jar -? -h --help; added -?. > jarsigner -? -h --help; added --help. -help accepted but not documented. > javac -? --help; added -?. Removed -help. -h is taken for other purpose > javadoc -? -h --help; added -h -?. Removed -help > javap -? -h --help; added -h. -help accepted but no more documented. > jcmd -? -h --help; added -? --help. -help accepted but no more > documented. Changed return value to '0' > jdb -? -h --help; added -? -h --help. -help accepted but no more > documented. > jdeprscan -? -h --help; added -? > jinfo -? -h --help; added -? --help. -help accepted but no more > documented. > jjs -h --help; Replaced -help by --help. Adding more not straight > forward. > jps -? -h --help; added -? --help. -help accepted but no more > documented. > jshell -? -h --help; added -? > jstat -? -h --help; added -h --help. -help accepted but no more > documented. > > Best regards, > Goetz.

2 3

RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947
by Xueming Shen 15 Dec '17

15 Dec '17

Hi Please help review the change for JDK-8193479 issue: https://bugs.openjdk.java.net/browse/JDK-8193479 webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev The internal interface ArrayEn/Decoder for ISO8859_1 has been removed because it is no longer used by StringCoding class, but it appears it is being used by hotspot Test6896617.java to verify the SSE instructions on x86. The proposed change here is to simply restore the internal interface ArrayEn/Decoder for ISO8859_1 to avoid blocking hotspot testing for now. thanks, Sherman

7 11

StringBuilder default constructor in the class library
by Hamada Abdelaziz 14 Dec '17

14 Dec '17

While analyzing GC pressure of a run time, I noticed the top object being a char[], upon a closer inspection, it turns out to be a result of ObjectStreamClass use of StringBuilder, which is constructed with the default size of 16 bytes. In such case 16 bytes is not a sufficient size, which leads to unnecessary garbage and incurs a performance hit. In a high volume situation this leads to high GC pressure, and in turn, non uniform performance. It's worthwhile revisiting all uses of StringBuilder default constructor in the class library and adjusting it appropriately. Thoughts?

2 1

RFR[10] 8193460 : Take tools/launcher/TestXcheckJNIWarnings.java back off the ProblemList
by Brent Christian 14 Dec '17

14 Dec '17

Hi, Way back five days ago[1], TestXcheckJNIWarnings.java was added to the ProblemList. Well, with a couple of recent fixes[2][3], this test can be taken back off of the ProblemList. --- a/test/jdk/ProblemList.txt Fri Dec 08 13:04:43 2017 -0800 +++ b/test/jdk/ProblemList.txt Wed Dec 13 09:28:01 2017 -0800 @@ -257,7 +257,6 @@ tools/pack200/CommandLineTests.java 8059906 generic-all tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all -tools/launcher/TestXcheckJNIWarnings.java 8190984 solaris-all tools/jimage/JImageExtractTest.java 8170120 generic-all Thanks, -Brent 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050496.h… 2. https://bugs.openjdk.java.net/browse/JDK-8193222 3. https://bugs.openjdk.java.net/browse/JDK-8190984

5 12

Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
by mandy chung 14 Dec '17

14 Dec '17

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193325/webrev.00/ This fixes the bug in hotspot that sets the bci field as int but it's of short type and also StackFrameInfo to return a proper bci value. Coleen suggests not to change set_bci to take jushort but instead do the cast as in the proposed fix. The VM is in favor of C++ types and stop propagation of Java types. bci is of int in VM implementation and so be consistent. Mandy [1] mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050581.html

3 3

[10!] RFR: 8193471: Startup regression due to JDK-8185582
by Claes Redestad 13 Dec '17

13 Dec '17

Hi, another startup regression due to very early use of lambdas and method refs that came in with JDK-8185582: Update Zip implementation to use Cleaner, not finalizers Webrev: http://cr.openjdk.java.net/~redestad/8193471/open.00/ /Claes

6 6

[10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line
by Vladimir Kozlov 13 Dec '17

13 Dec '17

http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8191788 This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 8190975 changes to fix that problem. This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and also test/jdk/java/lang/String/concat/WithSecurityManager.java I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). But it should be fine since it is only used with --limit-modules which is not used by Labs. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada

7 20

RFR: JDK-8184947:,ZipCoder performance improvements
by Xueming Shen 13 Dec '17

13 Dec '17

Hi, Please help review the changes for j.u.z.ZipCoder/JDK-8184947 (which also includes cleanup/improvement work in java.lang.StringCoding.java to speed up general String coding performance, especially for UTF8). issue: https://bugs.openjdk.java.net/browse/JDK-8184947 webrev: http://cr.openjdk.java.net/~sherman/8184947/webrev jmh benchmark: http://cr.openjdk.java.net/~sherman/8184947/ZipCodingBM.java http://cr.openjdk.java.net/~sherman/8184947/StringCodingBM.java Notes: (1) StringCoding.de/encode() for new String()/String.getBytes() with default charset. For historical reason the existing SC.decode(byte[], off, len)/encode(coder, val) implementation has code to handle any "possible" UnsupportedEncodingExcetion situation and turn to the slow "charset name" version of de/encode() for real work. Given the fact that the Charset.defaultCharset() now returns UTF8 as the fallback default charset if there is anything wrong to obtain a default charset (we did that in jdk7 or 8?), there is no need actually to handle the UEE. This also provides the opportunity to use fastpath for stateless UTF8/88591/ASCII de/encode(). The benchmark data for newString_xxx/ getBytes_xxx (which uses the default encoding, UTF8 in this case) suggests a big speed up fo ascii-only String. StringCodingBM size) Mode Cnt NEW Score Error OLD Score Error Units getBytes_ASCII 16 avgt 5 21.155 Â± 5.586 63.777 Â± 54.262 ns/op getBytes_ASCII 64 avgt 5 20.854 Â± 6.237 98.988 Â± 62.932 ns/op getBytes_ASCII 256 avgt 5 38.291 Â± 8.494 272.306 Â± 77.951 ns/op getBytes_Latin 16 avgt 5 80.968 Â± 15.814 76.769 Â± 38.512 ns/op getBytes_Latin 64 avgt 5 163.078 Â± 51.993 219.085 Â± 42.665 ns/op getBytes_Latin 256 avgt 5 759.548 Â± 99.386 824.594 Â± 763.735 ns/op getBytes_Unicode 16 avgt 5 94.311 Â± 22.189 124.185 Â± 32.751 ns/op getBytes_Unicode 64 avgt 5 289.603 Â± 152.056 321.541 Â± 103.703 ns/op getBytes_Unicode 256 avgt 5 1253.098 Â± 216.243 1201.667 Â± 512.532 ns/op newString_ASCII 16 avgt 5 33.273 Â± 13.780 50.402 Â± 17.574 ns/op newString_ASCII 64 avgt 5 30.420 Â± 6.207 84.989 Â± 43.355 ns/op newString_ASCII 256 avgt 5 54.391 Â± 10.451 208.096 Â± 102.716 ns/op newString_Latin 16 avgt 5 115.606 Â± 7.181 114.186 Â± 36.310 ns/op newString_Latin 64 avgt 5 393..710 Â± 73.478 414.286 Â± 176.837 ns/op newString_Latin 256 avgt 5 1618.967 Â± 289.044 1551.499 Â± 487.904 ns/op newString_Unicode 16 avgt 5 104.848 Â± 32.694 127.558 Â± 12.029 ns/op newString_Unicode 64 avgt 5 377.894 Â± 147.731 374.779 Â± 53.028 ns/op newString_Unicode 256 avgt 5 1557.977 Â± 318.652 1457.236 Â± 284.424 ns/op (2) updated to "fast path" UTF8/8859-1/ASCII in all de/coding operation, which are all implemented in static /stateless methods. (benchmark for MS932 [4] provide to make sure no regression for "other" charsets) (3) added "fast path" for "ascii-only' bytes for utf8 encoding/getBytes(). The benchmark [1] suggests a big speedup for ascii-only getBytes() with limited cost to non-ascii-only cases. (this helps big for (4), the ZipCoder situation, which mainly uses ascii only). (4) java.util.zip.ZipCoder This is where this patch actually started from. As the rfe suggested we are now using byte[] as the internal storage for the String class, the optimization we put in ZipCoder for UTF8 (which uses the byte[]/char[] interface of out UTF8 implementation to help avoid the relatively heavy ByteBuffer/CharBuffer coding interface) now appears to be not that "optimized". The to/from char[] copy/paste has become a waste. ZipCoder implementation can't use new String/String.getBytes() directly because of the the different malformed/unmappable character handing requirement. The proposed change here is to add a pair of special new String()/String.getBytes() in StrngCoding class to throw IAE instead of silent replacement, via (yet another) SharedSecrets interface. This brings us much faster de/encoding (30%-50% speed up) and much less memory usage (no more unnecessary byte[]/char[] allocation and in default mode, there is only ONE utf8 ZipCoder), on all "Jar/ZipEntry" related access operations. ZipCodeBenchMark [latest] * "New Score" is with the patch * getEntry() is mainly String.getBytes(), entries()/stream() is mainly new String(bytes)). Mode Cnt New Score Error Old Score Units jf_entries avgt 20 0.582 Â± 0.036 0.953 Â± 0.108 ms/op jf_getEntry avgt 20 1.506 Â± 0.158 2.052 Â± 0.171 ms/op jf_stream avgt 20 0.698 Â± 0.060 0.940 Â± 0.067 ms/op zf_entries avgt 20 0.691 Â± 0.057 0.917 Â± 0.080 ms/op zf_getEntry avgt 20 1.459 Â± 0.180 2.081 Â± 0.161 ms/op zf_stream avgt 20 0.626 Â± 0.074 0.909 Â± 0.075 ms/op Thanks, Sherman [1] http://cr.openjdk.java.net/~sherman/8184947/StringCoding.utf8 [2]http://cr.openjdk.java.net/~sherman/8184947/StringCoding.8859_1 [3] http://cr.openjdk.java.net/~sherman/8184947/StringCoding.ascii [4]http://cr.openjdk.java.net/~sherman/8184947/StringCoding.ms932 [5] http://cr.openjdk.java.net/~sherman/8184947/ZipCoding.bm

3 7