March 2021 - core-libs-dev

[PING] RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently
by yano-masanori＠fujitsu.com 03 Mar '21

03 Mar '21

Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -----Original Message----- > From: Yano, Masanori > Sent: Tuesday, January 12, 2021 4:32 PM > To: 'core-libs-dev(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> > Subject: RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty > segments inconsistently > > Hello, > > Please reply if anyone can be a sponsor. > > Regards, > Masanori Yano > > > -----Original Message----- > > From: Yano, Masanori > > Sent: Wednesday, December 23, 2020 5:01 PM > > To: 'core-libs-dev(a)openjdk.java.net' <core-libs-dev(a)openjdk.java.net> > > Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats > > empty segments inconsistently > > > > Hello, > > > > Please reply if anyone can be a sponsor. > > > > Regards, > > Masanori Yano > > > > > -----Original Message----- > > > From: Yano, Masanori > > > Sent: Wednesday, November 4, 2020 6:03 PM > > > To: 'core-libs-dev(a)openjdk.java.net' > > > <core-libs-dev(a)openjdk.java.net> > > > Subject: 8250678: ModuleDescriptor.Version parsing treats empty > > > segments inconsistently > > > > > > Hello. > > > > > > I would like to contribute for JDK-8250678. > > > > > > The 'parse' method of ModuleDescriptor.Version class behaves > > > incorrectly when the input string contains consecutive delimiters. > > > > > > The 'parse' method treats strings as three sections, but the parsing > > > method differs between the method for the version sections and the ones for > others. > > > In version sections, the 'parse' method takes a single character in > > > a loop and determines whether it is a delimiter. In pre and build > > > sections, the parse method takes two characters in a loop and > > > determines whether > > the second character is the delimiter. > > > Therefore, if the string contains a sequence of delimiters in pre or > > > build section, the 'parse' method treats character at the > > > odd-numbered position as a token and the one at even-numbered as a > > > delimiter > > > > > > A string containing consecutive delimiters is an incorrect version > > > string, but this behavior does not follow the API specification. > > > https://download.java.net/java/early_access/jdk16/docs/api/java.base > > > /j > > > ava/lang/ > > > module/ModuleDescriptor.Version.html > > > > > > Therefore, I propose to fix the parsing method of the pre section > > > and the build section in the same way as the version. > > > > > > Please sponsor the following change. > > > > > > diff -r bdc20ee1a68d > > > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > > > --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > > > Fri Sep 04 23:51:26 2020 -0400 > > > +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor. > > > +++ ja > > > +++ va > > > Wed Oct 28 17:06:47 2020 +0900 > > > @@ -1053,13 +1053,6 @@ > > > > > > while (i < n) { > > > c = v.charAt(i); > > > - if (c >= '0' && c <= '9') > > > - i = takeNumber(v, i, pre); > > > - else > > > - i = takeString(v, i, pre); > > > - if (i >= n) > > > - break; > > > - c = v.charAt(i); > > > if (c == '.' || c == '-') { > > > i++; > > > continue; > > > @@ -1068,6 +1061,10 @@ > > > i++; > > > break; > > > } > > > + if (c >= '0' && c <= '9') > > > + i = takeNumber(v, i, pre); > > > + else > > > + i = takeString(v, i, pre); > > > } > > > > > > if (c == '+' && i >= n) @@ -1075,17 +1072,14 @@ > > > > > > while (i < n) { > > > c = v.charAt(i); > > > + if (c == '.' || c == '-' || c == '+') { > > > + i++; > > > + continue; > > > + } > > > if (c >= '0' && c <= '9') > > > i = takeNumber(v, i, build); > > > else > > > i = takeString(v, i, build); > > > - if (i >= n) > > > - break; > > > - c = v.charAt(i); > > > - if (c == '.' || c == '-' || c == '+') { > > > - i++; > > > - continue; > > > - } > > > } > > > > > > this.version = v; > > > diff -r bdc20ee1a68d test/jdk/java/lang/module/VersionTest.java > > > --- a/test/jdk/java/lang/module/VersionTest.java Fri Sep 04 23:51:26 2020 > > > -0400 > > > +++ b/test/jdk/java/lang/module/VersionTest.java Wed Oct 28 17:06:47 > > > 2020 +0900 > > > @@ -148,6 +148,8 @@ > > > { "1", "1.0.0" }, > > > { "1.0", "1.0.0" }, > > > { "1.0-beta", "1.0.0-beta" }, > > > + { "1.0-1.1", "1.0-1..1" }, > > > + { "1.0-1+1", "1.0-1.+1" }, > > > > > > }; > > > } > > > > > > Regards, > > > Masanori Yano

1 0

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

Integrated: 8262096: Vector API fails to work due to VectorShape initialization exception
by Jie Fu 02 Mar '21

02 Mar '21

On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu <jiefu(a)openjdk.org> wrote: > 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… This pull request has now been integrated. Changeset: 40bdf52e Author: Jie Fu <jiefu(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/40bdf52e Stats: 60 lines in 2 files changed: 38 ins; 10 del; 12 mod 8262096: Vector API fails to work due to VectorShape initialization exception Reviewed-by: psandoz, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/2722

1 0

RFR: JDK-8262892: minor typo in implSpec comment
by Jonathan Gibbons 02 Mar '21

02 Mar '21

Please review a trivial fix to insert a missing word. ------------- Commit messages: - JDK-8262892: minor typo in implSpec comment Changes: https://git.openjdk.java.net/jdk/pull/2798/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2798&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262892 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2798/head:pull/2798 PR: https://git.openjdk.java.net/jdk/pull/2798

2 2

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v7]
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 incrementally with one additional commit since the last revision: Add VectorShape.getMaxVectorBitSize ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2722/files - new: https://git.openjdk.java.net/jdk/pull/2722/files/79402411..d3b4cc35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=05-06 Stats: 26 lines in 1 file changed: 16 ins; 6 del; 4 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

2 2

RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module
by Jonathan Gibbons 02 Mar '21

02 Mar '21

Please review some minor doc fixes, for issues found by _doccheck_. There are two kinds of errors that are addressed. 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs. In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`. 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc, ------------- Commit messages: - JDK-8262875: doccheck: empty paragraphs, etc in java.base module Changes: https://git.openjdk.java.net/jdk/pull/2795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262875 Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/2795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795 PR: https://git.openjdk.java.net/jdk/pull/2795

6 6

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception
by Paul Sandoz 02 Mar '21

02 Mar '21

On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu <jiefu(a)openjdk.org> wrote: > 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… @DamonFool that worked out better than i expected :-) One last thing i missed last time. The `PreferredSpeciesTest` also needs to be executed with no HotSpot flags. No need for another round of review. ------------- PR: https://git.openjdk.java.net/jdk/pull/2722

1 0

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