January 2021 - core-libs-dev

Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL
by Eirik Bjørsnøs 20 Jan '21

20 Jan '21

Hello, sun.net.www.protocol.jar.Handler.parseURL unconditionally calls String.substring twice on the spec string, even when ParseUtil.canonizeString later determines that no canonization was required. By letting canonizeString do the substring calls, but only when it determines that it is needed, we can remove some unnecessary String and byte[] allocations. Patch: https://github.com/eirbjo/jdk/commit/87da9032d7fb622f5d466f43faded4de672ebd… JMH micro: @Benchmark public void initURL(Blackhole blackhole) throws MalformedURLException { blackhole.consume(new URL(new URL("jar:file:/spring-aop.jar!/"), "org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.class")); } It shows a performance win for the patch in terms of throughput and bytes / operation: Baseline: Benchmark Mode Cnt Score Error Units ZipBenchmark.initURL thrpt 25 1673457.129 ± 22857.945 ops/s ZipBenchmark.initURL:·gc.alloc.rate thrpt 25 1410.227 ± 19.283 MB/sec ZipBenchmark.initURL:·gc.alloc.rate.norm thrpt 25 928.080 ± 0.005 B/op ZipBenchmark.initURL:·gc.churn.G1_Eden_Space thrpt 25 1412.557 ± 22.575 MB/sec ZipBenchmark.initURL:·gc.churn.G1_Eden_Space.norm thrpt 25 929.589 ± 5.756 B/op ZipBenchmark.initURL:·gc.churn.G1_Survivor_Space thrpt 25 0.006 ± 0.002 MB/sec ZipBenchmark.initURL:·gc.churn.G1_Survivor_Space.norm thrpt 25 0.004 ± 0.001 B/op ZipBenchmark.initURL:·gc.count thrpt 25 1441.000 counts ZipBenchmark.initURL:·gc.time thrpt 25 961.000 ms After: Benchmark Mode Cnt Score Error Units ZipBenchmark.initURL thrpt 25 1831971.983 ± 35705.091 ops/s ZipBenchmark.initURL:·gc.alloc.rate thrpt 25 1011.389 ± 19.689 MB/sec ZipBenchmark.initURL:·gc.alloc.rate.norm thrpt 25 608.061 ± 0.001 B/op ZipBenchmark.initURL:·gc.churn.G1_Eden_Space thrpt 25 1011.746 ± 20.583 MB/sec ZipBenchmark.initURL:·gc.churn.G1_Eden_Space.norm thrpt 25 608.275 ± 3.609 B/op ZipBenchmark.initURL:·gc.churn.G1_Survivor_Space thrpt 25 0.007 ± 0.001 MB/sec ZipBenchmark.initURL:·gc.churn.G1_Survivor_Space.norm thrpt 25 0.004 ± 0.001 B/op ZipBenchmark.initURL:·gc.count thrpt 25 1197.000 counts ZipBenchmark.initURL:·gc.time thrpt 25 760.000 ms Thanks, Eirik.

3 5

RFR: 8259947: Optimize UnixPath.encode
by Claes Redestad 20 Jan '21

20 Jan '21

This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization. This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark. ------------- Commit messages: - Add micro. To properly examine cost of toPath() needs a new File due caching - use FileOpen as a baseline - Optimize UnixPath.encode Changes: https://git.openjdk.java.net/jdk/pull/2135/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2135&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259947 Stats: 138 lines in 6 files changed: 79 ins; 45 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2135/head:pull/2135 PR: https://git.openjdk.java.net/jdk/pull/2135

4 15

[jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10
by Leo Jiang 20 Jan '21

20 Jan '21

This is the changes for JDK 16 msg drop 10. ------------- Commit messages: - JDK-8259732: JDK 16 L10n resource file update - msg drop 10 Changes: https://git.openjdk.java.net/jdk16/pull/123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=123&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259732 Stats: 215 lines in 30 files changed: 118 ins; 16 del; 81 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123

2 10

RFR: 8259867: Move encoding checks into ZipCoder
by eirbjo 20 Jan '21

20 Jan '21

ZipFile.Source.initCEN verifies that entry names are encoding into bytes valid in the entry's encoding. It does so by calling encoding-specific checking methods, so it also needs to determine which check method to call for each entry. By moving the encoding-variant checks into ZipCoder, initCEN can instead simply call ZipCoder.checkEncoding. This makes the code easier to follow and also removes a duplication of flag checking logic found in zipCoderForPos. ------------- Commit messages: - 8242959: Move name encoding checks to ZipCoder (cleanup) Changes: https://git.openjdk.java.net/jdk/pull/2110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259867 Stats: 58 lines in 2 files changed: 27 ins; 28 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2110/head:pull/2110 PR: https://git.openjdk.java.net/jdk/pull/2110

3 3

RFR: Merge jdk16
by Jesper Wilhelmsson 19 Jan '21

19 Jan '21

Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8259796: timed CompletableFuture.get may swallow InterruptedException The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2151&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2151&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/2151/files Stats: 88 lines in 2 files changed: 29 ins; 26 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2151/head:pull/2151 PR: https://git.openjdk.java.net/jdk/pull/2151

1 1

IllegalStateException in CharsetDecoder when inspecting JarFile contents on Java 15
by Vitaly Davidovich 19 Jan '21

19 Jan '21

Hi all, I observed the following stacktrace when inspecting a JarFile's contents using a parallel stream (i.e. FJ pool): Exception in thread "main" java.lang.IllegalStateException: java.lang.IllegalStateException: Current state = CODING_END, new state = FLUSHED at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481) at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:600) at java.base/java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:678) at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:737) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:575) at <stripped>.ClassVersions.conflicts(ClassVersions.java:703) at <stripped>.ClassVersions.check(ClassVersions.java:743) at <stripped>.ClassVersions.main(ClassVersions.java:839) Caused by: java.lang.IllegalStateException: Current state = CODING_END, new state = FLUSHED at java.base/java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:998) at java.base/java.nio.charset.CharsetDecoder.flush(CharsetDecoder.java:681) at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:810) at java.base/java.util.zip.ZipCoder.normalizedHashDecode(ZipCoder.java:136) at java.base/java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash(ZipCoder.java:228) at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1527) at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1249) at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1211) at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:701) at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:240) at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:171) at java.base/java.util.jar.JarFile.<init>(JarFile.java:347) at java.base/java.util.jar.JarFile.<init>(JarFile.java:318) at java.base/java.util.jar.JarFile.<init>(JarFile.java:284) at <stripped>.ClassVersions.lookupJar(ClassVersions.java:665) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290) at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183) (Note: I stripped off some package names to protect the innocent). While investigating this a bit, I noticed some code that looks a bit suspect. Namely: - ZipCoder has a singleton UTF8ZipCoder <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa22…> instance it uses for UTF8 decoding. - Source.get() creates a new Source <https://github.com/openjdk/jdk/blob/05bcd67e6501f3824020edd1ab036c87888fa22…> instance outside of any synchronization The links above are to tip, but I think this code is the same in Java 15. It seems possible that multiple threads can end up in Source.get(), new up a Source, and proceed to use the decoder of UTF8ZipCoder racily. Per my understanding (and CharsetDecoder javadoc), CharsetDecoders are not threadsafe. Any thoughts? Did I miss anything that would suggest the stacktrace above is due to something else entirely? Thanks

2 3

RFR: 8132984: incorrect type for Reference.discovered
by Kim Barrett 19 Jan '21

19 Jan '21

Please review this change which fixes the type of the private Reference.discovered field. It was Reference<T>, but that's wrong because it can be any Reference object. I've changed it to Reference<?> and let that flow through, updating some other variables that were previously somewhat incorrectly typed (usually with an Object type parameter). The interesting change is to the ReferenceQueue.enqueue parameter, which is now also Reference<?>. This ultimately end up with a provably safe and correct, but uncheckable, cast in ReferenceQueue.enqueue. An alternative might be to use a raw type for the discovered field, but I think that ends up with more @SuppressWarnings of various flavors. I think the unbounded wildcard approach is clearer and cleaner. Note that all of the pending list handling, including the discovered field, could be moved into a non-public, non-generic, sealed(?) base class of Reference<T>. The pending list handling has nothing to do with the generic parameter T. Testing: mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run) ------------- Commit messages: - Use unbounded wildcard placeholders and final safe but unchecked cast Changes: https://git.openjdk.java.net/jdk/pull/1897/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1897&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8132984 Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1897.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1897/head:pull/1897 PR: https://git.openjdk.java.net/jdk/pull/1897

6 11

[jdk16] RFR: 8259796: timed CompletableFuture.get may swallow InterruptedException
by Martin Buchholz 19 Jan '21

19 Jan '21

8259796: timed CompletableFuture.get may swallow InterruptedException ------------- Commit messages: - JDK-8259796 Changes: https://git.openjdk.java.net/jdk16/pull/126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=126&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259796 Stats: 87 lines in 2 files changed: 28 ins; 26 del; 33 mod Patch: https://git.openjdk.java.net/jdk16/pull/126.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/126/head:pull/126 PR: https://git.openjdk.java.net/jdk16/pull/126

3 5

Performance regression in BuiltinClassLoader?
by Eirik Bjørsnøs 19 Jan '21

19 Jan '21

Hello, I've been looking into ZipFile again with the aim to speed up typical enterprise classloading / resource lookups. To test the performance impact of my changes, I made a benchmark which creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar files in Spring Petclinic (89 jars with ~30k entries total). (This is intentionally implemented using a plain main method with no JMH or warmup since I want to measure a representative cold application startup) The benchmark measures the time needed to call getResource 30K times, once for each entry name. Using 15.0.1, this completes in ~1700 ms Using 17 master, it completes in 12851 ms If I run the benchmark from the classpath instead of as a module, the result is even worse: 15: 1724 ms 17: 21885 ms If also measure GC collections and times, and get the following: 15: Collections: 4 Collection time: 12 ms 17: Collections: 24 Collection time: 44 ms (However, a JHM with -prof gc indicates that both 17 and 15 allocate ~5.6Kb/getResource after warmup, so not convinced this needs to be allocation related) The EnterpriseClassLoader is a bit clever in that it can perform lookups using different strategies: Regular parent-first, self-only, or use the bootstrap / platform system classloaders directly. Here are the results on 17 using each strategy (benchmark on class path): PARENT_DELEGATION: 23111 ms SELF_ONLY: 428 ms BOOTSTRAP: 8131 ms PLATFORM: 15149 ms SYSTEM: 20628 ms Here are the same results on 15: PARENT_DELEGATION: 1691 ms SELF_ONLY: 393 ms BOOTSTRAP: 579 ms PLATFORM: 908 ms SYSTEM: 1368 ms Note that the delegation chain is Enterprise -> System -> Platform -> Bootstrap. Interesting to note that URLClassLoader itself does not seem to regress much when only looking up its own resources, while delegating up the chain does. Has there been any significant work in class loading / resource lookup since 15.0.1 that could help explain this regression? Eirik.

4 10

A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive
by Johannes Kuhn 18 Jan '21

18 Jan '21

Let's start with the reproducer: public class NestmateBug { private static int field = 0; public static void main(String[] args) throws Throwable { Lookup l = MethodHandles.lookup(); Field f = NestmateBug.class.getDeclaredField("field"); MethodHandle mh = l.findVirtual(Field.class, "setInt", methodType(void.class, Object.class, int.class)); int newValue = 5; mh.invokeExact(f, (Object) null, newValue); } } This throws a IAE in the last line: class test.se15.NestmateBug$$InjectedInvoker/0x0000000800bb5840 (in module test.se15) cannot access a member of class test.se15.NestmateBug (in module test.se15) with modifiers "private static" at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385) at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:693) at java.base/java.lang.reflect.Field.checkAccess(Field.java:1096) at java.base/java.lang.reflect.Field.setInt(Field.java:976) at test.se15/test.se15.NestmateBug.main(NestmateBug.java:17) The reason for this behaviour is: * Field.setInt (without setAccessible) requires that the caller class is in the same nest for private members. * Field.setInt is @CallerSensitive * MethodHandles will bind to the caller by injecting an invoker for @CallerSensitive methods. * The injected invoker is NOT a nestmate of the original lookup class. * The access check of Field.setInt fails - as the injected invoker is now the caller. This is important because: * Some old software loves to set static final fields through reflection. * To do that, it usually hacks into Field.modifiers. Which is filtered iirc since Java 12. * I write Java agents to fix such things - removing final from static fields, and intercept Class.getDeclaredField and Field.setInt by replacing it with an invokedynamic instruction. * The original target is passed as a MethodHandle bootstrap argument. In the case of Field.setInt, it is guarded with a MethodHandles.guardWithTest() - calling the original target if the Field is not my canary. Suggested fix: * Make the injected invoker a nestmate of lookup class. I did prepare a fix for that [1], but AFAIK the bug first needs to be filled in the bug tracker. And I don't have an account. - Johannes [1]: https://github.com/DasBrain/jdk/commit/3c4bb20c8e4cd9086e934128e5cb085a5cfb…

3 10