January 2021 - core-libs-dev

RFR: 8252412: [macos11] File-based loading of dynamic libraries deprecated
by Martin Buchholz 23 Jan '21

23 Jan '21

8252412: [macos11] File-based loading of dynamic libraries deprecated ------------- Commit messages: - JDK-8252412: [macos11] File-based loading of dynamic libraries deprecated Changes: https://git.openjdk.java.net/jdk/pull/2119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2119&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252412 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2119/head:pull/2119 PR: https://git.openjdk.java.net/jdk/pull/2119

4 10

RFR: 8246788: ZoneRules invariants can be broken
by Stuart Marks 22 Jan '21

22 Jan '21

Tighten up argument checking in constructor. ------------- Commit messages: - 8246788: ZoneRules invariants can be broken Changes: https://git.openjdk.java.net/jdk/pull/2191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246788 Stats: 90 lines in 2 files changed: 87 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2191/head:pull/2191 PR: https://git.openjdk.java.net/jdk/pull/2191

5 7

RFR: 8259707: LDAP channel binding does not work with StartTLS extension
by Alexey Bakhtin 22 Jan '21

22 Jan '21

Please review a small patch to enable LDAP TLS Channel Binding with StartTLS Extension. Test from the bug report and jtreg javax/naming tests are passed. ------------- Commit messages: - 8259707: LDAP channel binding does not work with StartTLS extension Changes: https://git.openjdk.java.net/jdk/pull/2085/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2085&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259707 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2085.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2085/head:pull/2085 PR: https://git.openjdk.java.net/jdk/pull/2085

4 20

RFR: 8259922 MethodHandles.collectArguments does not follow its documentation
by Johannes Kuhn 22 Jan '21

22 Jan '21

Add explicit range check to `MethodHandles.collectArgumentsCheck`. Added test case that exercises all cases. This is a behavioral change, from throwing an unspecified exception to throwing an IllegalArgumentException, as specified. No spec change needed, as the IllegalArgumentException is already specified to be thrown in those cases. Feel free to suggest a better place for the tests. ------------- Commit messages: - Fix tailing whitespace in in MethodHandles.java - Fix copyright yeahr in MethodHandles.java - Fix JDK-8259922 - Fix JDK-8259922. Changes: https://git.openjdk.java.net/jdk/pull/2171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259922 Stats: 100 lines in 2 files changed: 99 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2171/head:pull/2171 PR: https://git.openjdk.java.net/jdk/pull/2171

2 7

RFR: 8259842: Remove Result cache from StringCoding
by Claes Redestad 22 Jan '21

22 Jan '21

The `StringCoding.resultCached` mechanism is used to remove the allocation of a `StringCoding.Result` object on potentially hot paths used in some `String` constructors. Using a `ThreadLocal` has overheads though, and the overhead got a bit worse after JDK-8258596 which addresses a leak by adding a `SoftReference`. This patch refactors much of the decode logic back into `String` and gets rid of not only the `Result` cache, but the `Result` class itself along with the `StringDecoder` class and cache. Microbenchmark results: Baseline Benchmark (charsetName) Mode Cnt Score Error Units decodeCharset US-ASCII avgt 15 193.043 ± 8.207 ns/op decodeCharset:·gc.alloc.rate.norm US-ASCII avgt 15 112.009 ± 0.001 B/op decodeCharset ISO-8859-1 avgt 15 164.580 ± 6.514 ns/op decodeCharset:·gc.alloc.rate.norm ISO-8859-1 avgt 15 112.009 ± 0.001 B/op decodeCharset UTF-8 avgt 15 328.370 ± 18.420 ns/op decodeCharset:·gc.alloc.rate.norm UTF-8 avgt 15 224.019 ± 0.002 B/op decodeCharset MS932 avgt 15 328.870 ± 20.056 ns/op decodeCharset:·gc.alloc.rate.norm MS932 avgt 15 232.020 ± 0.002 B/op decodeCharset ISO-8859-6 avgt 15 193.603 ± 12.305 ns/op decodeCharset:·gc.alloc.rate.norm ISO-8859-6 avgt 15 112.010 ± 0.001 B/op decodeCharsetName US-ASCII avgt 15 209.454 ± 9.040 ns/op decodeCharsetName:·gc.alloc.rate.norm US-ASCII avgt 15 112.009 ± 0.001 B/op decodeCharsetName ISO-8859-1 avgt 15 188.234 ± 7.533 ns/op decodeCharsetName:·gc.alloc.rate.norm ISO-8859-1 avgt 15 112.009 ± 0.001 B/op decodeCharsetName UTF-8 avgt 15 399.463 ± 12.437 ns/op decodeCharsetName:·gc.alloc.rate.norm UTF-8 avgt 15 224.019 ± 0.003 B/op decodeCharsetName MS932 avgt 15 358.839 ± 15.385 ns/op decodeCharsetName:·gc.alloc.rate.norm MS932 avgt 15 208.017 ± 0.003 B/op decodeCharsetName ISO-8859-6 avgt 15 162.570 ± 7.090 ns/op decodeCharsetName:·gc.alloc.rate.norm ISO-8859-6 avgt 15 112.009 ± 0.001 B/op decodeDefault N/A avgt 15 316.081 ± 11.101 ns/op decodeDefault:·gc.alloc.rate.norm N/A avgt 15 224.019 ± 0.002 B/op Patched: Benchmark (charsetName) Mode Cnt Score Error Units decodeCharset US-ASCII avgt 15 159.153 ± 6.082 ns/op decodeCharset:·gc.alloc.rate.norm US-ASCII avgt 15 112.009 ± 0.001 B/op decodeCharset ISO-8859-1 avgt 15 134.433 ± 6.203 ns/op decodeCharset:·gc.alloc.rate.norm ISO-8859-1 avgt 15 112.009 ± 0.001 B/op decodeCharset UTF-8 avgt 15 297.234 ± 21.654 ns/op decodeCharset:·gc.alloc.rate.norm UTF-8 avgt 15 224.019 ± 0.002 B/op decodeCharset MS932 avgt 15 311.583 ± 16.445 ns/op decodeCharset:·gc.alloc.rate.norm MS932 avgt 15 208.018 ± 0.002 B/op decodeCharset ISO-8859-6 avgt 15 156.216 ± 6.522 ns/op decodeCharset:·gc.alloc.rate.norm ISO-8859-6 avgt 15 112.010 ± 0.001 B/op decodeCharsetName US-ASCII avgt 15 180.752 ± 9.411 ns/op decodeCharsetName:·gc.alloc.rate.norm US-ASCII avgt 15 112.010 ± 0.001 B/op decodeCharsetName ISO-8859-1 avgt 15 156.170 ± 8.003 ns/op decodeCharsetName:·gc.alloc.rate.norm ISO-8859-1 avgt 15 112.010 ± 0.001 B/op decodeCharsetName UTF-8 avgt 15 370.337 ± 22.199 ns/op decodeCharsetName:·gc.alloc.rate.norm UTF-8 avgt 15 224.019 ± 0.001 B/op decodeCharsetName MS932 avgt 15 312.589 ± 15.067 ns/op decodeCharsetName:·gc.alloc.rate.norm MS932 avgt 15 208.018 ± 0.002 B/op decodeCharsetName ISO-8859-6 avgt 15 173.205 ± 9.647 ns/op decodeCharsetName:·gc.alloc.rate.norm ISO-8859-6 avgt 15 112.009 ± 0.001 B/op decodeDefault N/A avgt 15 303.459 ± 16.452 ns/op decodeDefault:·gc.alloc.rate.norm N/A avgt 15 224.019 ± 0.001 B/op Most variants improve. There's a small added overhead in `String charsetName` variants for some charsets such as `ISO-8859-6` that benefited slightly from the `StringDecoder` cache due avoiding a lookup, but most variants are not helped by this cache and instead see a significant gain from skipping that step. `Charset` variants don't need a lookup and improve across the board. Another drawback is that we need to cram more logic into `String` to bypass the `StringCoding.Result` indirection - but getting rid of two commonly used `ThreadLocal` caches and most cases getting a bit better raw throughput in the process I think more than enough makes up for that. Testing: tier1-4 ------------- Commit messages: - Remove unused imports - Merge branch 'master' into sc_tl_exp - Fix charset names in micro settings - Refactor charset lookups to ensure expected exceptions are thrown on null, foo etc - Cleanup includes etc - Cleanups, minor improvements - More micro fixes - resolve merge - Fix micro - Add simple StringDecode micro - ... and 3 more: https://git.openjdk.java.net/jdk/compare/707bce08...f14826b1 Changes: https://git.openjdk.java.net/jdk/pull/2102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259842 Stats: 1170 lines in 4 files changed: 592 ins; 543 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/2102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2102/head:pull/2102 PR: https://git.openjdk.java.net/jdk/pull/2102

4 33

RFR: 8259943: FileDescriptor.close0 does not handle EINTR
by Brian Burkhalter 21 Jan '21

21 Jan '21

Please review this small change to handle `EINTR` from `close()` in `fileDescriptorClose()`. The function `handleGetLength()` is also changed to handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the file. ------------- Commit messages: - 8259943: FileDescriptor.close0 does not handle EINTR Changes: https://git.openjdk.java.net/jdk/pull/2173/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2173&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259943 Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2173.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2173/head:pull/2173 PR: https://git.openjdk.java.net/jdk/pull/2173

4 10

RFR: Merge jdk16
by Jesper Wilhelmsson 21 Jan '21

21 Jan '21

Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259757: add a regression test for 8259353 and 8259601 - 8259732: JDK 16 L10n resource file update - msg drop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2176&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2176/files Stats: 296 lines in 31 files changed: 200 ins; 16 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/2176.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2176/head:pull/2176 PR: https://git.openjdk.java.net/jdk/pull/2176

1 1

RFR: 8259498: Reduce overhead of MD5 and SHA digests
by Claes Redestad 20 Jan '21

20 Jan '21

- The MD5 intrinsics added by [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the `int[] x` isn't actually needed. This also applies to the SHA intrinsics from which the MD5 intrinsic takes inspiration - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to make it acceptable to use inline and replace the array in MD5 wholesale. This improves performance both in the presence and the absence of the intrinsic optimization. - Doing the exact same thing in the SHA impls would be unwieldy (64+ element arrays), but allocating the array lazily gets most of the speed-up in the presence of an intrinsic while being neutral in its absence. Baseline: (digesterName) (length) Cnt Score Error Units MessageDigests.digest MD5 16 15 2714.307 ± 21.133 ops/ms MessageDigests.digest MD5 1024 15 318.087 ± 0.637 ops/ms MessageDigests.digest SHA-1 16 15 1387.266 ± 40.932 ops/ms MessageDigests.digest SHA-1 1024 15 109.273 ± 0.149 ops/ms MessageDigests.digest SHA-256 16 15 995.566 ± 21.186 ops/ms MessageDigests.digest SHA-256 1024 15 89.104 ± 0.079 ops/ms MessageDigests.digest SHA-512 16 15 803.030 ± 15.722 ops/ms MessageDigests.digest SHA-512 1024 15 115.611 ± 0.234 ops/ms MessageDigests.getAndDigest MD5 16 15 2190.367 ± 97.037 ops/ms MessageDigests.getAndDigest MD5 1024 15 302.903 ± 1.809 ops/ms MessageDigests.getAndDigest SHA-1 16 15 1262.656 ± 43.751 ops/ms MessageDigests.getAndDigest SHA-1 1024 15 104.889 ± 3.554 ops/ms MessageDigests.getAndDigest SHA-256 16 15 914.541 ± 55.621 ops/ms MessageDigests.getAndDigest SHA-256 1024 15 85.708 ± 1.394 ops/ms MessageDigests.getAndDigest SHA-512 16 15 737.719 ± 53.671 ops/ms MessageDigests.getAndDigest SHA-512 1024 15 112.307 ± 1.950 ops/ms GC: MessageDigests.getAndDigest:·gc.alloc.rate.norm MD5 16 15 312.011 ± 0.005 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-1 16 15 584.020 ± 0.006 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-256 16 15 544.019 ± 0.016 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-512 16 15 1056.037 ± 0.003 B/op Target: Benchmark (digesterName) (length) Cnt Score Error Units MessageDigests.digest MD5 16 15 3134.462 ± 43.685 ops/ms MessageDigests.digest MD5 1024 15 323.667 ± 0.633 ops/ms MessageDigests.digest SHA-1 16 15 1418.742 ± 38.223 ops/ms MessageDigests.digest SHA-1 1024 15 110.178 ± 0.788 ops/ms MessageDigests.digest SHA-256 16 15 1037.949 ± 21.214 ops/ms MessageDigests.digest SHA-256 1024 15 89.671 ± 0.228 ops/ms MessageDigests.digest SHA-512 16 15 812.028 ± 39.489 ops/ms MessageDigests.digest SHA-512 1024 15 116.738 ± 0.249 ops/ms MessageDigests.getAndDigest MD5 16 15 2314.379 ± 229.294 ops/ms MessageDigests.getAndDigest MD5 1024 15 307.835 ± 5.730 ops/ms MessageDigests.getAndDigest SHA-1 16 15 1326.887 ± 63.263 ops/ms MessageDigests.getAndDigest SHA-1 1024 15 106.611 ± 2.292 ops/ms MessageDigests.getAndDigest SHA-256 16 15 961.589 ± 82.052 ops/ms MessageDigests.getAndDigest SHA-256 1024 15 88.646 ± 0.194 ops/ms MessageDigests.getAndDigest SHA-512 16 15 775.417 ± 56.775 ops/ms MessageDigests.getAndDigest SHA-512 1024 15 112.904 ± 2.014 ops/ms GC MessageDigests.getAndDigest:·gc.alloc.rate.norm MD5 16 15 232.009 ± 0.006 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-1 16 15 584.021 ± 0.001 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-256 16 15 272.012 ± 0.015 B/op MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-512 16 15 400.017 ± 0.019 B/op For the `digest` micro digesting small inputs is faster with all algorithms, ranging from ~1% for SHA-512 up to ~15% for MD5. The gain stems from not allocating and reading into a temporary buffer once outside of the intrinsic. SHA-1 does not see a statistically gain because the intrinsic is disabled by default on my HW. For the `getAndDigest` micro - which tests `MessageDigest.getInstance(..).digest(..)` there are similar gains with this patch. The interesting aspect here is verifying the reduction in allocations per operation when there's an active intrinsic (again, not for SHA-1). JDK-8259065 (#1933) reduced allocations on each of these with 144B/op, which means allocation pressure for SHA-512 is down two thirds from 1200B/op to 400B/op in this contrived test. I've verified there are no regressions in the absence of the intrinsic - which the SHA-1 numbers here help show. ------------- Commit messages: - Remove unused Unsafe import - Harmonize MD4 impl, remove now-redundant checks from ByteArrayAccess (VHs do bounds checks, most of which will be optimized away) - Merge branch 'master' into improve_md5 - Apply allocation avoiding optimizations to all SHA versions sharing structural similarities with MD5 - Remove unused reverseBytes imports - Copyrights - Fix copy-paste error - Various fixes (IDE stopped IDEing..) - Add imports - mismatched parens - ... and 8 more: https://git.openjdk.java.net/jdk/compare/090bd3af...e1c943c5 Changes: https://git.openjdk.java.net/jdk/pull/1855/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1855&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259498 Stats: 649 lines in 8 files changed: 83 ins; 344 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/1855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1855/head:pull/1855 PR: https://git.openjdk.java.net/jdk/pull/1855

3 17

RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469
by Claes Redestad 20 Jan '21

20 Jan '21

This patch resolves a thread-safety issue where the singleton UTF8ZipCoder is erroneously using a shared CharsetDecoder when the fast-path fails. It needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469 This should resolve a rare issue when doing a lot of jar scanning in parallel on jar/zip files (with at least some non-ASCII entries), but I've not managed to create a test that reliably reproduce the issue. ------------- Commit messages: - UTF8ZipCoder.normalizedHash not thread-safe Changes: https://git.openjdk.java.net/jdk/pull/2163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260010 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2163/head:pull/2163 PR: https://git.openjdk.java.net/jdk/pull/2163

3 5

RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException
by Claes Redestad 20 Jan '21

20 Jan '21

Change `MethodHandles.byteArrayViewVarHandle` to throw `ArrayIndexOutOfBoundsException` rather than the more generic `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the risk for subtle behavioral mismatch when migrating code from arrays/Unsafe to VHs. CSR: [JDK-8259912](https://bugs.openjdk.java.net/browse/JDK-8259912) ------------- Commit messages: - byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Changes: https://git.openjdk.java.net/jdk/pull/2124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2124&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259911 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2124.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2124/head:pull/2124 PR: https://git.openjdk.java.net/jdk/pull/2124

4 9