February 2021 - core-libs-dev

RFR: 8260664: Phaser.arrive() memory consistency effects
by Martin Buchholz 08 Mar '21

08 Mar '21

8260664: Phaser.arrive() memory consistency effects ------------- Commit messages: - JDK-8260664 Changes: https://git.openjdk.java.net/jdk/pull/2388/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260664 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2388.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2388/head:pull/2388 PR: https://git.openjdk.java.net/jdk/pull/2388

2 3

ThreadLocal lookup elimination
by Eirik Bjørsnøs 06 Mar '21

06 Mar '21

Hello, ThreadLocals are commonly used to transfer state across method boundaries in situations where passing them as method parameters is impractical. Examples include crossing APIs you don't own, or instrumenting code you don't own. Consider the following pseudo-instrumented code (where the original code calls a getter inside a loop): public class Student { private int age; public int maxAge(Student[] students) { // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); // Original code: int max = 0; for (Student student : students) { max = Math.max(max, student.getAge()); } return max; } public int getAge() { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code: return age; } // Instrumented field: private static ThreadLocal<ExpensiveObject> threadLocal = new ThreadLocal<>(); } The ThreadLocal is used here to avoid constructing ExpensiveObject instances in each invocation of getAge. However, once a compiler worth its salt sees this code, it immediately wants to inline the getAge method: // Instrumented code: ExpensiveObject expensive = new ExpensiveObject(); expensive.recordSomething(); threadLocal.set(expensive); for (Student student : students) { // Instrumented code ExpensiveObject exp = threadLocal.get(); exp.recordSomething(); // Original code max = Math.max(max, student.age); } At this point, we see that the last write to threadLocal is 'expensive', so any following 'threadLocal.get()' should be substitutable for 'expensive'. So we could do the following instead: for (Student student : students) { // Instrumented code expensive.recordSomething(); // Original code max = Math.max(max, student.age); } More generally, a compiler could record the first lookup of a ThreadLocal in a scope and substitute any following lookup with the first read (until the next write). I'm pretty sure this would be immensely useful for my current use case (which instruments methods to count invocations), but perhaps it is also a useful optimization in a more general sense? Examples that come to mind are enterprise apps where transaction and security contexts are passed around using ThreadLocals. Has this type of optimization been discussed before? Is it even possible to implement, or did I miss some dragons hiding in the details? What would the estimated work for an implementation look like? Are we looking at bachelor's thesis? Master's thesis? PhD? Would love to hear some thoughts on this idea. Cheers, Eirik.

3 5

RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized*
by Ian Graves 05 Mar '21

05 Mar '21

Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one. ------------- Commit messages: - Changing Collections.unmodifiable* to idempotent behavior. Changes: https://git.openjdk.java.net/jdk/pull/2596/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6323374 Stats: 281 lines in 2 files changed: 281 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2596.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596 PR: https://git.openjdk.java.net/jdk/pull/2596

8 39

RFR: 8166026: Refactor java/lang shell tests to java
by Ivan Šipka 03 Mar '21

03 Mar '21

Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test. ------------- Commit messages: - 8166026: Refactor java/lang shell tests to java Changes: https://git.openjdk.java.net/jdk/pull/1577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8166026 Stats: 501 lines in 6 files changed: 196 ins; 305 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577 PR: https://git.openjdk.java.net/jdk/pull/1577

4 31

RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently
by Maurizio Cimadamore 03 Mar '21

03 Mar '21

This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout. The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances. ------------- Commit messages: - Reduce concurrency in handshake test Changes: https://git.openjdk.java.net/jdk/pull/2748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260869 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2748/head:pull/2748 PR: https://git.openjdk.java.net/jdk/pull/2748

2 5

RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
by Attila Szegedi 02 Mar '21

02 Mar '21

8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" ------------- Commit messages: - 8261483: Try to eliminate flakiness of the test by extending its allowed runtime and reducing the memory Changes: https://git.openjdk.java.net/jdk/pull/2617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261483 Stats: 6 lines in 3 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2617/head:pull/2617 PR: https://git.openjdk.java.net/jdk/pull/2617

3 18

RFR: 8261670: Add javadoc for the XML processing limits
by Joe Wang 02 Mar '21

02 Mar '21

Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide. ------------- Commit messages: - 8261670: Add javadoc for the XML processing limits Changes: https://git.openjdk.java.net/jdk/pull/2732/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261670 Stats: 87 lines in 1 file changed: 81 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/2732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2732/head:pull/2732 PR: https://git.openjdk.java.net/jdk/pull/2732

4 14

Inconsistency in Constructor.getGenericParameterTypes()
by Oliver Drotbohm 02 Mar '21

02 Mar '21

Previously sent to the wrong list. Sorry for the double post. Von: Oliver Drotbohm <odrotbohm(a)vmware.com> Betreff: Inconsistency in Constructor.getGenericParameterTypes() Datum: 25. Februar 2021 um 10:03:12 MEZ An: jdk-dev(a)openjdk.java.net Hi all, we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that? Here's a the output of a reproducer (below): static class StaticGeneric<T> - names: value, string static class StaticGeneric<T> - parameters: [class java.lang.Object, class java.lang.String] static class StaticGeneric<T> - generic parameters: [T, class java.lang.String] class NonStaticGeneric<T> - names: this$0, value, String class NonStaticGeneric<T> - parameters: [class Sample, class java.lang.Object, class java.lang.String] class NonStaticGeneric<T> - generic parameters: [T, class java.lang.String] class NonStaticNonGeneric - names: this$0, String class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String] class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String] Note how the constructor of the NonStaticGeneric<T> type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types. Tested on JDK 8 to 15. Same behavior. Cheers, Ollie class Sample { public static void main(String[] args) { Constructor<?> first = StaticGeneric.class.getDeclaredConstructors()[0]; System.out.println("static class StaticGeneric<T> - names: " + Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("static class StaticGeneric<T> - parameters: " + Arrays.toString(first.getParameterTypes())); System.out.println( "static class StaticGeneric<T> - generic parameters: " + Arrays.toString(first.getGenericParameterTypes())); System.out.println(); Constructor<?> second = NonStaticGeneric.class.getDeclaredConstructors()[0]; System.out.println("class NonStaticGeneric<T> - names: " + Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("class NonStaticGeneric<T> - parameters: " + Arrays.toString(second.getParameterTypes())); System.out .println( "class NonStaticGeneric<T> - generic parameters: " + Arrays.toString(second.getGenericParameterTypes())); System.out.println(); Constructor<?> third = NonStaticNonGeneric.class.getDeclaredConstructors()[0]; System.out.println("class NonStaticNonGeneric - names: " + Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", "))); System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes())); System.out .println( "class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes())); } static class StaticGeneric<T> { StaticGeneric(T value, String string) {} } class NonStaticGeneric<T> { NonStaticGeneric(T value, String String) {} } class NonStaticNonGeneric { NonStaticNonGeneric(String String) {} } }

3 5

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5]
by Jie Fu 02 Mar '21

02 Mar '21

> Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2). > > Vector API should not depend on C2 to run. > It should work even there is no JIT compiler since it's a Java-level api. > So let's fix it. > > Testing: > - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSu… Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Fix in jdk/incubator/vector/VectorShape.java - Merge branch 'master' into JDK-8262096 - Revert changes - Remove -XX:TieredStopAtLevel=3 - Update the jtreg test - The numerator should be 8 (byte) - 8262096: Vector API fails to work due to VectorShape initialization exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/bbe6150c..b67b232d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03-04 Stats: 7047 lines in 380 files changed: 3707 ins; 1675 del; 1665 mod Patch: https://git.openjdk.java.net/jdk/pull/2722.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722 PR: https://git.openjdk.java.net/jdk/pull/2722

3 5

RFR: JDK-8261839: Error creating runtime package on macos without mac-pack…
by Andy Herrick 01 Mar '21

01 Mar '21

…age-identifier ------------- Commit messages: - JDK-8261839: Error creating runtime package on macos without mac-package-identifier Changes: https://git.openjdk.java.net/jdk/pull/2730/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261839 Stats: 24 lines in 4 files changed: 8 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/2730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2730/head:pull/2730 PR: https://git.openjdk.java.net/jdk/pull/2730

4 5